Re: Appstream + Gnome
On Wed, 01 Jan 2020 at 13:17:34 +0100, Jeff wrote:
> One of my packages is an application and ships a .desktop file and
> appstream xml. The tracker.debian.org page for the package complained
> that the ID for package didn't follow the {tld}.{vendor}.{product}
> scheme[1], so I modified so that it did.
My understanding is that downstream distributors like Debian should
not be changing the AppStream ID: this is something that should be done
in a coordinated way by the package's upstream developers, so that all
downstream distributions (both traditional OS distributions like Debian
and Fedora, and app frameworks "above" the OS like Flatpak and Snap)
end up using the same ID.
The AppStream ID and the .desktop filename will usually also need to be
coordinated. For example, GNOME Builder (package name and executable:
gnome-builder) ships /usr/share/applications/org.gnome.Builder.desktop,
which means its freedesktop.org app ID (derived from the .desktop file)
is "org.gnome.Builder.desktop", and its AppStream ID needs to be either
"org.gnome.Builder.desktop" or "org.gnome.Builder". (In fact it's the
latter, so it has /usr/share/metainfo/org.gnome.Builder.appdata.xml.)
Again, any changes to the .desktop filename should happen upstream first.
> Now I have a report from a Gnome 3 user that since the above change, it
> is no longer possible to add the application as a "favorite".
GNOME Shell stores favourite apps as a list of freedesktop.org app IDs
(basically the basenames of .desktop files).
> It seems that adding an application is only possible in Gnome 3 if the
> ID is exactly the same as the executable name.
There are several linked identifiers that should ideally be the same:
the .desktop file, the AppStream ID, the Wayland xdg_toplevel app ID
(if using Wayland), the X11 RESOURCE_NAME (if using X11), the X11
class name and window class (if using X11), and the D-Bus-style
reversed-domain-name GApplication name (if using GApplication). Many of
those are derived from each other, and from higher-level application
metadata, by libraries like GLib and GTK. In the GLib ecosystem they
cannot all have the right defaults for the reversed-domain-name naming
style, particularly in older code that doesn't use GApplication, because
that would be a backwards-compatibility break.
If you're using GLib, check that g_get_prgname() (which defaults to the
basename of the executable) is what you want it to be. When using a
reversed-domain-name app ID but not using GApplication, passing the
D-Bus-style reversed-domain-name to g_set_prgname() might be necessary.
> Given there seem to be plenty of gnome-* applications that use the
> {tld}.{vendor}.{product} scheme, I seem to be missing something.
It might be helpful to find an application written with the same
library stack as yours that moved from name-of-executable.desktop to
com.example.App(.desktop) as its app ID, and check what else changed
during that transition.
smcv
Reply to: