GNOME Bugzilla – Bug 769641
Mismatched application id with xdg-shell
Last modified: 2018-05-02 17:22:40 UTC
The executable name is used as application id instead of the actual application id. Let's take Calendar as an example, but the same can be verified with other applications. The desktop entry is org.gnome.Calendar.desktop but the executable name is passed on as application id: [1895038,114] -> xdg_shell@16.get_xdg_surface(new id xdg_surface@27, wl_surface@15) [1895038,123] -> xdg_surface@27.set_parent(nil) [1895038,127] -> xdg_surface@27.set_title("Calendar") [1895038,130] -> xdg_surface@27.set_window_geometry(26, 23, 996, 713) [1895038,139] -> xdg_surface@27.set_maximized() [1895038,142] -> xdg_surface@27.set_app_id("gnome-calendar") This makes mapping Gtk+ applications on task managers really hard.
Jonas, iirc you touched this area in the past ?
Yes. The problem is that we don't have the information available in Gdk to set it to the correct thing. In the past I made an attempt to force everyone to start setting the prgname (g_set_prgname()) to the application ID (since some were already doing it and its the closest thing we had). Eventually that was reverted since it just switched what set of applications were broken to a different set. Another attempt was to use the GApplication ID (the one that becomes the D-Bus name), but for various applications that didn't match with the actual application ID which was not the D-Bus name. They could not change their application ID to the D-Bus name because that'd mean they had to change the .desktop file name, which would break favorites, bookmarks etc. I think since then there was some idea floating around making .desktop file aliases or something which I suspect could possibly solve that particular issue. The "cleanest" way would maybe be to force every application to use ID used as the GApplication application-id, i.e. rename their .desktop files and maybe create aliases (if that makes the problem go away), and then have GTK pass that down as a gdk_window_set_app_id() (instead of gdk_window_set_dbus_properties_libgtk_only). It'd definitely break things again, until all applications have been updated, which is not very optimal, but it's the most "correct" way IMHO. FWIW, I suspect in the Calendar example, the correct ID will be passed via the gtk_surface1.set_dbus_properties request.
Can't give any suggestion on how to do it because I don't know much the Gtk+/GDK internals but it was working with gtk-shell. My compositor implements gtk-shell and I received the application ID from there, which was sufficient but that is no longer working - the clients don't seem to bind anymore, perhaps I have an old version advertised. That said resort to a non-public protocol such as gtk-shell is problematic especially for Qt-based compositor, and it can change version any time breaking compatibility with older Gtk+ applications. FWIW, with Qt 5.7 I added a QGuiApplication for the desktop file name and application developers should really set that property if they want their application to work reliably on Wayland. There is still some guessing when the property is not set, reverse the domain name (if set) and concatenate with the executable name. Works on most cases but the desktop file name property is the best way. Perhaps Gtk+ could do add that property to GApplication and keep separate the GApplication ID from the desktop file name. Most of the time they will be pretty much the same so the desktop file name could be initialized to the application ID.
(In reply to Jonas Ådahl from comment #2) > > The "cleanest" way would maybe be to force every application to use ID used > as the GApplication application-id, i.e. rename their .desktop files and > maybe create aliases (if that makes the problem go away), and then have GTK > pass that down as a gdk_window_set_app_id() (instead of > gdk_window_set_dbus_properties_libgtk_only). flatpak enforces the idea of app-id == bus name == desktop file name, so we're moving towards this.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
This issue is still relevant, how can I reopen it? The Status dropdown only has NEEDINFO and RESOLVED, none of them applies.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/653.