Add metainfo.xml for Flatpak, etc.

[elsiehupp]

metainfo.xml is part of the FreeDesktop AppStream specification and is used to generate product pages on various software-distribution front-ends, in particular Flatpak. Much of the content of metainfo.xml overlaps with the .desktop file, but metainfo.xml can contain additional metadata of particular use in, e.g., GNOME Software.

I initially updated the metainfo.xml on the Flathub repository with additional info from the .desktop file, but @tilosp recommended I submit the metainfo upstream instead in order for the changes to percolate out to other distribution endpoints (like Fedora).

The main benefit of adding metainfo.xml to the main Nextcloud Desktop repository is that it would help keep the product-page metadata consistent between the various downstream distribution points.

[tilosp]

I think this should get integrated into cmake the same way the desktop file already is. This way it get automatically installed by the build system and the template system could be used for app-id and name.

[tilosp]

@nextcloud/desktop how does the release process currently work, would it be possible to somehow add the same changelog here as in the github release?

Otherwise i would make sense to autogenerate this section using cmake to keep it up to date.

[elsiehupp]

It looks like the version tag is added to the build in git2changelog.py, but I don’t know exactly what would be involved in creating the list in XML. Presumably it would involve Python writing directly to XML and reconstructing the version list from scratch, which is a bit beyond me at the moment (though idk I could look into it regardless).

[tilosp]

thanks i didn't know about git2changelog.py.

IMHO the changelog integration is not nessesary and could be added later on.

The main problem is see with this currently is that either someone has to update it manually or it will become out of date on the next release. One simple solution would be to have only a single release in the meta-info file, and set it using templates. So maybe using @MIRALL_VERSION@ but i am not sure where the date would come from.

[elsiehupp]

/rebase

[elsiehupp]

By the way, I left the Nextcloud screenshot because I assume it would be unchanged for OEM builds. (Also there aren’t any existing CMake variables for screenshots.)

[elsiehupp]

One big issue, by the way, is that APPLICATION_REV_DOMAIN is com.nextcloud.desktopclient, while the Flathub ID is com.nextcloud.desktopclient.nextcloud.desktop. I assume the Flathub ID is this doubled-up string for historical reasons, but the mismatch is probably going to be a problem.

[nextcloud-desktop-bot]

AppImage file: Nextcloud-PR-3281-2d4c519114802f61e2b7b0467f122040b2e1a632-x86_64.AppImage

To test this change/fix you can simply download above AppImage file and test it.

Please make sure to quit your existing Nextcloud app and backup your data.

[tilosp]

One big issue, by the way, is that APPLICATION_REV_DOMAIN is com.nextcloud.desktopclient, while the Flathub ID is com.nextcloud.desktopclient.nextcloud.desktop. I assume the Flathub ID is this doubled-up string for historical reasons, but the mismatch is probably going to be a problem.

APPLICATION_REV_DOMAIN it not actually the app-id, the app id is stored in LINUX_APPLICATION_ID

desktop/src/gui/CMakeLists.txt

Lines 437 to 438 in 20357ca

	configure_file(${CMAKE_SOURCE_DIR}/mirall.desktop.in
	${CMAKE_CURRENT_BINARY_DIR}/${LINUX_APPLICATION_ID}.desktop)

which gets set from concatenating APPLICATION_REV_DOMAIN and LINUX_PACKAGE_SHORTNAME

desktop/NEXTCLOUD.cmake

Line 16 in 4efe00f

set( LINUX_APPLICATION_ID "${APPLICATION_REV_DOMAIN}.${LINUX_PACKAGE_SHORTNAME}")

So the real app-id is com.nextcloud.desktopclient.nextcloud which matches with flathub.

[tilosp]

this should go next to the desktop file since it should only be used on linux

desktop/src/gui/CMakeLists.txt

Lines 437 to 439 in 20357ca

	configure_file(${CMAKE_SOURCE_DIR}/mirall.desktop.in
	${CMAKE_CURRENT_BINARY_DIR}/${LINUX_APPLICATION_ID}.desktop)
	install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${LINUX_APPLICATION_ID}.desktop DESTINATION ${DATADIR}/applications )

and it should also get installed like the desktop file, so something like this:

configure_file(${CMAKE_SOURCE_DIR}/metainfo.xml.in 
               ${CMAKE_CURRENT_BINARY_DIR}/${LINUX_APPLICATION_ID}.metainfo.xml) 
install(FILES  ${CMAKE_CURRENT_BINARY_DIR}/${LINUX_APPLICATION_ID}.metainfo.xml DESTINATION ${DATADIR}/metainfo )

[FlexW]

Before reviewing this, @elsiehupp could you please make the intent of your pr clear. What will be the benefit?

EDIT: I see you marked it as draft, but regardless please explain your intent when doing a pr.

[elsiehupp]

Before reviewing this, @elsiehupp could you please make the intent of your pr clear. What will be the benefit?

EDIT: I see you marked it as draft, but regardless please explain your intent when doing a pr.

I edited the main PR description to explain the purpose of the file. Basically metainfo.xml is already used downstream, and incorporating it in the main repository would help keep the various downstream copies properly synchronized.