<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Epiphany displays incorrect name in gnome-shell app menu" href="https://bugzilla.gnome.org/show_bug.cgi?id=752258#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Epiphany displays incorrect name in gnome-shell app menu" href="https://bugzilla.gnome.org/show_bug.cgi?id=752258">bug 752258</a> from <a href="page.cgi?id=describeuser.html&login=jstpierre%40mecheye.net" title="Jasper St. Pierre <jstpierre@mecheye.net>"> Jasper St. Pierre</a> <pre>(In reply to Michael Catanzaro from <a href="show_bug.cgi?id=752258#c14">comment #14</a>) > First up: if an application calls g_set_prgname(), it must set the prgname > to the name of its desktop file. That's been the case for as long as I > remember. It sounds like your change is designed to "fix" applications that > renamed their desktop files without changing g_set_prgname accordingly? > have a bogus call to g_set_prgname(). No, it must set the prgname to the name of your binary. If you have a binary called "gedit" and a desktop file of org.gnome.gedit.desktop, it is entirely legal to keep your prgname as gedit, because then "killall gedit" works fine. (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=752258#c13">comment #13</a>) > The linked GTK+ commit is an attempt to implement the client<->shell Wayland > protocol (xdg_shell) more properly. The reason that triggered the change was > that applications that had transitioned te being D-Bus activatable (i.e. > renamed their .desktop file) would no longer match correctly because the > prgname would no longer match the .desktop file and gnome-shell was not able > to figure out what window was part of what application (i.e. the same as > this bug). I don't believe that. With X11, we have two fields: WM_CLASS, and _GTK_APPLICATION_ID. None of this is ever documented officially, because application matching is all heuristics, because we never put in real ways for people to tie X11 Windows, DBus names, .desktop files and PIDs together. Up until now, we've been relying on WM_CLASS matching and _GTK_APPLICATION_ID (along with a few other heuristics like StartupWMClass thrown in for good measure -- please ignore them). For DBus activatable apps, we use _GTK_APPLICATION_ID. For any other app, we use WM_CLASS. With Wayland, we have two equivalent fields: xdg_surface.set_app_id, and gtk_surface.set_gtk_application_id. xdg_surface.set_app_id should match WM_CLASS / the .desktop file for non-DBus activatable apps. That means it should match the prgname, and set_gtk_application_id will catch the other cases. What were the cases where it was breaking before? Lots of things use the desktop file ID as a key into storage, or use it to determine desktop settings (app-specific notification settings, for instance, are based on it), so renaming it has a cost. If the user adds it to a list of favorites, for instance, they'll lose that when the app updates.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>