<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#c14">Comment # 14</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=mcatanzaro%40gnome.org" title="Michael Catanzaro <mcatanzaro@gnome.org>"> Michael Catanzaro</a> <pre>(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). 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? I think applications doing the transition to D-Bus activation should not call g_set_prgname() at all: that's redundant with the GApplication ID. The only reason to set the prgname is to override the GApplication ID to match the desktop file, which is pointless if the desktop file uses reverse-DNS already. With this approach, we don't break applications that have not yet transitioned to D-Bus activation. And the smaller set of applications that have done the transition can be responsible for their own breakage if they have a bogus call to g_set_prgname(). > One of the problems is that in the future, for GtkApplications the > application id passed there will most likely always be correct, but there is > no way for the GDK backend to know if it actually is that. The most "future > proof" was then decided to be to default to the GtkApplication ID when > available, and fallback to prgname. > > I don't think reverting the commit is preferable since it would make GTK+ to > more or less always set the incorrect application ID (according to the > xdg_shell protocol). I know that the same ID is available via the > set_dbus_properties request in gtk_shell, but that does not change the fact > that we should properly implement the xdg_shell protocol. Two questions from me: * Why do you think preferring the GtkApplication ID with fallback to prgname (new behavior that has broken applications) is preferable to the previous behavior preferring prgname with fallback to GtkApplication ID? (Note, GtkApplication actually sets prgname to the GtkApplication ID if it has not already been set, so the GDK X11 backend might not actually be checking the app ID, but the effect is the same as if it did.) * If we keep this change in the Wayland backend, should we not change the X11 backend as well to match? It seems like a bad idea to have the behavior differ between the two backends. > While the IMHO "proper" fix is to fix all the GtkApplications, a possible > transition-phase work-around is to add a "set_legacy_prgname" to gtk_shell > or "gtk_legacy_shell" or something that can then be propogated to > gnome-shell so that it can match applications who has not updated to the new > conventions. > > It'd introduce multiple ID's per application in Wayland similar to how it is > in X, but at least it'd be more clearly marked as "legacy". Oh gosh, it would surely be easier to just fix all the GtkApplications. :p</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>