Re: Appstream + Gnome
On 03/01/2020 00:48, Simon McVittie wrote:
> Glib::Object::Introspection->invoke("GLib", undef, "set_prgname",
> "com.example.Test");
I hadn't thought of that!
Up to now, I'd only seen GIO used for gtk, and it didn't occur to me to
try it.
The user has confirmed that this solves the problem. Thanks for your help.
> Either way I'd recommend reporting the absence of g_set_prgname() as a bug
> (or at least a feature request), since it's sometimes necessary to control
> what GLib thinks the program's basename is.
I'll work up a patch as soon as I get a moment.
Regards
Jeff
signature.asc
Description: OpenPGP digital signature
Re: Appstream + Gnome
Am Do., 2. Jan. 2020 um 21:58 Uhr schrieb Jeff : > > On 02/01/2020 16:53, Matthias Klumpp wrote: > > @Jeff Did your changes include adding a launchable tag? If not, adding > > one may already fix this issue. > > Yes, I had. > > > When transitioning: > > 1) Make sure you add a launchable tag - it may not be essential, but > > it certainly is more explicit. Also, you'll get a validator info hint > > if you don't have one. > > 2) Add the old ID to , so tools can still associate older > > data with the new name (if they ćare about that) > > The workaround I've found is to duplicate the .desktop file, one with > the correct ID, and one matching the executable name. Ah! In this case renaming of the .desktop file probably was the issue? Since you have two .desktop files now, make sure the old one has either NoDisplay=True set, or contains the X-AppStream-Ignore=True field (or both), otherwise your application will appear twice in software centers. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: Appstream + Gnome
On Thu, 02 Jan 2020 at 22:07:04 +0100, Jeff wrote:
> On 01/01/2020 21:34, Simon McVittie wrote:
> > 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.
>
> This is probably the real solution, but unfortunately, my application is
> Perl, not pure C, and g_set_prgname() is not in the Perl bindings for
> glib (yet).
It isn't in the more curated Glib module, but if you're
using a GObject-Introspection-based auto-generated binding via
GLib::Object::Introspection, all the functions should be available
*somehow*. I've never used GLib from Perl before, so there's probably
a better way, but this lower-level code seems to work:
use strict;
use warnings;
use Glib::Object::Introspection;
use Gtk3;
Glib::Object::Introspection->invoke("GLib", undef, "set_prgname",
"com.example.Test");
print Glib::Object::Introspection->invoke("GLib", undef, "get_prgname");
Or, if there's an equivalent of Python's ctypes in Perl, g_set_prgname
is hopefully not too hard to call through that? It takes one UTF-8 string
argument and doesn't return anything.
Or, can you use GtkApplication or GApplication from Perl? (Gtk3::Application
and Glib::IO::Application, I suspect.)
Either way I'd recommend reporting the absence of g_set_prgname() as a bug
(or at least a feature request), since it's sometimes necessary to control
what GLib thinks the program's basename is.
smcv
Re: Appstream + Gnome
On 01/01/2020 21:34, Simon McVittie wrote: > Again, any changes to the .desktop filename should happen upstream first. In this case, I am also upstream. But your point is well made. > 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. This is probably the real solution, but unfortunately, my application is Perl, not pure C, and g_set_prgname() is not in the Perl bindings for glib (yet). I'll add it, and confirm whether g_set_prgname() fixes the problem when the updated bindings have filtered down to the users. Thanks for all the help. Regards Jeff signature.asc Description: OpenPGP digital signature
Re: Appstream + Gnome
On 02/01/2020 16:53, Matthias Klumpp wrote: > @Jeff Did your changes include adding a launchable tag? If not, adding > one may already fix this issue. Yes, I had. > When transitioning: > 1) Make sure you add a launchable tag - it may not be essential, but > it certainly is more explicit. Also, you'll get a validator info hint > if you don't have one. > 2) Add the old ID to , so tools can still associate older > data with the new name (if they ćare about that) The workaround I've found is to duplicate the .desktop file, one with the correct ID, and one matching the executable name. Thanks for the insight. Regards Jeff signature.asc Description: OpenPGP digital signature
Re: Appstream + Gnome
Hi everyone!
Sorry for the delayed reply, I was busy with traveling around during
the new year. For that matter: Happy new year! :-)
I am the upstream maintainer of AppStream as well as in Debian.
Am Mi., 1. Jan. 2020 um 13:17 Uhr schrieb Jeff :
>
> Firstly - apologies for sending this to -devel. Please point me at a
> better place to ask the question if there is one.
I don't think there's one explicitly for Debian. The Freedesktop
mailinglist occasionally gets distro-related questions, and if you
suspect a bug a report against src:appstream will work. But I am also
fine with this on d-devel.
> 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.
>
> 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".
To clarify: Do they claim it's no longer possible to add the app as
favourite in GNOME Shell, or in the GNOME Software app?
> [...]
Am Mi., 1. Jan. 2020 um 21:35 Uhr schrieb Simon McVittie :
>
> 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.
Exactly, and this is actually a very important thing in AppStream. IDs
should be static and shouldn't be changed by individual downstream
projects, because that makes the software component essentially a
different one in the eyes of AppStream. That can lead to multiple
issues, like tools using the data getting confused when fetching
information about the software, or ratings and reviews not getting
attributed to the right software.
The validator hint exists to basically forward this issue upstream and
ask them to change the ID if it's a new application - new AppStream
metainfo files should ideally not ever start with a non-reverse-DNS
ID. That the other scheme exists is a mistake of the past, which we
will now support forewer. This also means that if the app doesn't
follow the rDNS scheme, they may not want to change the ID if the old
one has been established for years. That's fine too in that case.
A way to transition IDs exists by putting the old ID as a provided ID, like so:
```
tld.domain.MyCoolApp
mycoolapp.desktop
```
Some tools (but not all!) will do the right thing then and merge
external data associated with both IDs.
Since the warning originates from the upstream metainfo file
validator, the message is light on info about what we as a
*distributor* should actually do.
I am very tempted to implement a way to override this particular
message to make it much more clear to Debian developers on what to do
here, or maybe even to potentially hide this particular issue from the
developer dashboard / issue pages (not sure what is better here, the
former feels a bit more honest to do). Do you (Simon, Jeff, Mattia)
have any preferences / ideas on that?
> 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.
It was this way in the past, but nowadays AppStream is *way* more
explicit. Older versions of AppStream were a pretty useful hack to
"just get the info we need quickly" and were tailored much more for
being autogenerated data for distributions. Nowadays, with newer
versions, a lot of the magic has been drained from the spec and pretty
much every change should now be explicit, focusing much more on making
metainfo files easy to write and understand by humans.
That means in this case in particular: You can pick literally and rDNS
name for your component that you want, as long as no other app is
using it already. That creates a component that is, initially, not
launchable. This is sometimes desired, for example WINE is a
type=desktop-application GUI application that doesn't have a "main
app" that works on its
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
Re: Appstream + Gnome
On Wed, Jan 01, 2020 at 01:17:34PM +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.
>
> 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".
>
> It seems that adding an application is only possible in Gnome 3 if the
> ID is exactly the same as the executable name.
>
> Given there seem to be plenty of gnome-* applications that use the
> {tld}.{vendor}.{product} scheme, I seem to be missing something.
I was likewise hit by a similar issue. It seems to be a Wayland bug,
rather than a Gnome bug though.
Also, none of the Gnome application are affected due to their heavy use
of Glib stuff that do enough magic to keep everythign working.
See https://bugs.debian.org/942600
https://gitlab.com/inkscape/inkscape/issues/539
If anybody could also help with my bug above, that would be awesome.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Appstream + Gnome
Firstly - apologies for sending this to -devel. Please point me at a
better place to ask the question if there is one.
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.
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".
It seems that adding an application is only possible in Gnome 3 if the
ID is exactly the same as the executable name.
Given there seem to be plenty of gnome-* applications that use the
{tld}.{vendor}.{product} scheme, I seem to be missing something.
How can I pick an ID that satisfies the appstream parser referred to by
tracker.debian.org, and allows Gnome 3 users to add the application as a
favorite?
Regards
Jeff
[1]
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-id-generic
signature.asc
Description: OpenPGP digital signature
