Open A6GibKm opened 1 year ago
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 https://github.com/projecthamster/hamster/issues/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:
<launchable>
item that can be used to explicitly reference a .desktop file by nameI 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?
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
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?
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.
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 https://github.com/projecthamster/hamster/issues/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.