App ids don't match

[A6GibKm]

App is using org.gnome.Hamster.GUI as an app id, but in multiple places it is also using org.gnome.Hamster, this causes multiple issues. prob causes #713 and similar issues. Note that the app at flathub is using the wrong app id.

Note that the actual id is set here https://github.com/projecthamster/hamster/blob/master/src/hamster-cli.py#L113.

[matthijskooijman]

While looking into flatpak metadata and versioning, I also noticed some id discrepancies and investigated. Since the outcome seems applicable to this issue, I'll add my findings here.

App is using org.gnome.Hamster.GUI as an app id, but in multiple places it is also using org.gnome.Hamster, this causes multiple issues. prob causes #713 and similar issues. Note that the app at flathub is using the wrong app id.

It seems this is intentional (see #538), since there are three distinct (dbus) services contained in this single "application": GUI, the hamster db service and (legacy) windowing service, which use org.gnome.Hamster.GUI, org.gnome.Hamster and org.gnome.Hamster.WindowServer for their respective dbus services.

It seems that there are multiple places that use their own id namespace (dbus, gtk app, flatpak id, desktop files, metainfo.xml), some of which are expected to match. I've looked around and found a number of requirements on these names:

• Debian wiki documents that the metainfo id should match the desktop file id. The appstream spec does not seem to document this requirement, but does show a <launchable> item that can be used to explicitly reference a .desktop file by name
• I believe the desktop file should match the GTK application ID (for the window manager to match the application window to the desktop file?). The GTK application uses org.gnome.Hamster.GUI.
• A flatpak application also needs a metainfo.xml file to describe it, whose name must match the flatpak application id. The flatpak application now uses org.gnome.Hamster (not .GUI), which makes sense since it contains all three services, not just the GUI.
• A flatpak application should have a .desktop file that matches the flatpak id.
• For dbus activation configured in a .desktop file, the .desktop filename must match the corresponding DBUS name.
• Dbus itself does not seem to require any particular naming convention (except for the common tld.domain type of convention)

I think these are conflicting requirements - we cannot just use org.gnome.Hamster everywhere except dbus, since that breaks dbus activation. But mismatching the flatpak id with the desktop file and metainfo file also seems to be wrong (and prevent flatpak from picking up the metainfo file at least).

One thing to observe is that basically only the flatpak build seems to suffer from issues stemming from the multiple ids, the regular build just offers multiple dbus services and matches the desktop and other files to the .GUI name. Or is anyone seeing other issues?

One obvious solution would be to rename the flatpak application to org.gnome.hamster.GUI, which I think would solve these issues by making the application id the same everywhere (and just have two additional dbus ids), but that doesn't feel right to use the .GUI as the main flatpak id when it contains more than just that.

Another option could be to drop dbus activation from the desktop file, which, I think, no longer restricts the .desktop filename (which can then just be org.gnome.Hamster.desktop), but then starting hamster when the GUI is already running results in running the hamster binary being ran (which still seems to activate the existing window, probably because it sends a message over dbus if already running), which is less elegant.

In hindsight, making the GUI dbus service org.gnome.Hamster and the data server org.gnome.Hamster.Something could have sidestepped this issue, but compatibility probably makes that a moot point.

As for the metainfo.xml file, I guess we could (ignoring the other problems for now) just drop the .GUI from that and then violate the (probably weak - only found on the Debian wiki) requirement to match the metainfo with the desktop file, so the flatpak build can use the metainfo file.

Also, it seems that ignoring the requirement that the desktop filename should match the flatpak id also works (that's what our upstream flatpak build does, which does not suffer from #692, which is probably the same as #713, both of which likely are issues with the flathub version that renames the .desktop file).

Summarizing: I'm unsure what the best approach is, maybe someone has suggestions? @tchernobog @rabin-io maybe?

[A6GibKm]

In short, everything should match the GTK id set on application_id (metainfo, flatpak id, desktop file, icon file name, etc).

If you own extra dbus interfaces you can use the --own-name=OTHER_DBUS_INTERFACE cleanup arg in the flatpak manifest, that way flatpak will know you are also listening on those.

There is an example at https://github.com/flathub/org.gnome.FileRoller/blob/master/org.gnome.FileRoller.json#L13

[matthijskooijman]

As for the metainfo.xml file, I guess we could (ignoring the other problems for now) just drop the .GUI from that and then violate the (probably weak - only found on the Debian wiki) requirement to match the metainfo with the desktop file, so the flatpak build can use the metainfo file.

This has been implemented as part of #738 and allows Flatpak to see the metainfo.xml file and the version number contained inside.

In short, everything should match the GTK id set on application_id (metainfo, flatpak id, desktop file, icon file name, etc).

@A6GibKm Given the context of the current Hamster application, that effectively means we would need to rename the Flatpak application from org.gnome.Hamster to org.gnome.Hamster.GUI. Does that make sense? Intuitively that feels wrong, since the GUI is just part of the app itself?

[A6GibKm]

Yes, it is awkward but that just the APP ID that is used by the app. Either you do that, or rename the org.gnome.Hamster service to something else and use org.gnome.Hamster instead of org.gnome.Hamster.GUI, the former makes more sense to me.