GNOME Bugzilla – Bug 685742
Window class of terminals doesn't match the desktop file name
Last modified: 2021-06-10 20:23:01 UTC
In current git master (future 3.8), the window class of terminals is Gnome-terminal-server, but gnome-shell expects Gnome-terminal to correctly associate desktop files. A simple fix is to call gdk_set_program_class after GTK is initalized (i.e. in GtkApplication->startup). Alternatively, you can call g_set_prgrname before option parsing, but that would affect --help and the default log handler, so it's better to avoid it.
I'd prefer using gdk_set_program_class(). While the g_set_prgname() wouldn't matter for the options (the server is autostarted from dbus and should never be called manually), that would affect e.g. debug output. (It's not quite established yet that master will be 3.8, btw.)
Fixed on master; please verify.
Yes, this bug is fixed now. Thanks!
This fix is 'too much' because it sets the class even if --class is explicitly given on the commandline. Besides: probably the best thing to do is to rename the desktop file to org.gnome.Terminal and set the wmclass to the same thing as the appid.
Note: I am not blocked on this because gnome-shell takes _GTK_APPLICATION_ID in preference to WMCLASS anyway. This is more of a theoretical complaint: if --class is given, we shouldn't stomp on it.
The patch also sets the class to "gnome-terminal" even when --app-id is given. Setting it to the application id in that case is preferable, so that window managers treat terminal windows with different app ids differently. In general, I think it's unreasonable that gnome-terminal has to call gtk_init_with_args() just to parse the --app-id option. One of the main points of GtkApplication is that users don't need to call gtk_init() anymore. Thus, I've added support for --app-id in GApplication (see bug #743933) and ported gnome-terminal to that. Setting WM_CLASS to the app's id is a good idea for all applications, so I've attached a patch to the same bug that makes GtkApplication do that. We can remove the call to gdk_set_program_class() in gnome-terminal. These patches are blocked on bug #743933.
Created attachment 296088 [details] [review] server.c: don't call g_application_register() g_application_run() will call it anyway and return with the same error when an instance already exists.
Created attachment 296089 [details] [review] server: use GApplication's --app-id support So that we don't have to handle that option in server.c by calling gtk_init_with_args(). gtk_init() is called in GtkApplication anyway.
Created attachment 296090 [details] [review] TerminalApp: don't call gdk_set_program_class() GtkApplication now calls it with the application's id. That makes more sense than always setting it to "gnome-terminal", as window managers should distinguish between terminals which were started with different --app-ids.
(In reply to comment #5) > Note: I am not blocked on this because gnome-shell takes _GTK_APPLICATION_ID in > preference to WMCLASS anyway. This is more of a theoretical complaint: if > --class is given, we shouldn't stomp on it. So just changing this /* Need to set the WM class (bug #685742) */ gdk_set_program_class("Gnome-terminal"); to this /* Set the WM class to the app ID (see bug #685742) */ gdk_set_program_class(g_application_get_application_id(application)); will work today, with no glib/gtk changes required as in bug #743933 ? If so, let's just go with that instead of this patch series.
(In reply to comment #10) > So just changing this > > /* Need to set the WM class (bug #685742) */ > gdk_set_program_class("Gnome-terminal"); > > to this > > /* Set the WM class to the app ID (see bug #685742) */ > gdk_set_program_class(g_application_get_application_id(application)); > > will work today, with no glib/gtk changes required as in bug #743933 ? If so, > let's just go with that instead of this patch series. Yes, that will achieve the same effect right now (it still doesn't handle the --class problem, but my patches don't, either). Ryan has been thinking about adding --app-id support to GApplication for a while. When stumbling across this bug because a friend's terminal profiles files were breaking on unity, I took the occasion and finally added support for that in GApplication. So no, the glib and gtk+ patches aren't strictly necessary to solve this bug, but they'll greatly simplify terminal's code and make the same functionality available to other apps. Btw, the first patch is only marginally related and can be applied anyways. It just removes some unnecessary lines.
I've committed the first patch and the change from comment 10.
Reopening. The change (6c91fa9) breaks the Unity bar's contents in two different ways. Previously, "Terminal" was displayed in bold when the menu was not opened, and was displayed twice next to each other (actually a total of 3 times which is not ideal) after pressing Alt or hovering with the mouse. Now the application name is the title of the active tab from the first opened gnome-terminal window (that is: not necessarily the currently focused window). And the second label becomes "Unknown Application Name". Screenshots follow. (Note: my title is the tty number.)
Created attachment 297683 [details] Before
Created attachment 297684 [details] After
(In reply to Egmont Koblinger from comment #13) > Reopening. The change (6c91fa9) breaks the Unity bar's contents in two > different ways. > > Previously, "Terminal" was displayed in bold when the menu was not opened, > and was displayed twice next to each other (actually a total of 3 times > which is not ideal) after pressing Alt or hovering with the mouse. > > Now the application name is the title of the active tab from the first > opened gnome-terminal window (that is: not necessarily the currently focused > window). And the second label becomes "Unknown Application Name". Unity uses WM_CLASS to look up the desktop file for an application. It cannot find the desktop file anymore because after this patch WM_CLASS is set to 'org.gnome.Terminal', but the desktop file is still called 'gnome-terminal.desktop'. The same happens in GNOME Shell. We should either revert this patch or rename the desktop file to org.gnome.Terminal.desktop. Renaming will probably cause quite a few migration problems. I recommend doing that at the start of a cycle.
(In reply to Lars Uebernickel from comment #16) > Renaming will probably cause quite a few > migration problems. I recommend doing that at the start of a cycle. Thanks for your input. I agree, let's revert now and figure out the proper way of doing this in the early 0.41 days. ChPe?
(In reply to Lars Uebernickel from comment #16) > We should either revert this patch or rename the desktop file to > org.gnome.Terminal.desktop. Renaming will probably cause quite a few > migration problems. I recommend doing that at the start of a cycle. I have a patch to rename the desktop file to org.gnome.Terminal.desktop in bug 711059
Reverted for now.
(In reply to Debarshi Ray from comment #18) > I have a patch to rename the desktop file to org.gnome.Terminal.desktop in > bug 711059 I've tried that patch, it suffers from the exact same problem under Ubuntu's Unity than the one we reverted here for the same reason. It's not just a visual problem, I also had problems with the launcher icon. I removed the launcher icon from the left-hand launcher bar, then started g-t manually from xterm. The icon appeared in the left-hand bar, and I locked it to the launcher. Quit g-t, and clicked on this icon: it was not able to start g-t.
(In reply to Egmont Koblinger from comment #20) > (In reply to Debarshi Ray from comment #18) > > > I have a patch to rename the desktop file to org.gnome.Terminal.desktop in > > bug 711059 > > I've tried that patch, it suffers from the exact same problem under Ubuntu's > Unity than the one we reverted here for the same reason. *shrug* I don't see the same problem in gnome-shell. In fact I have been running gnome-terminal with org.gnome.Terminal.desktop on my systems for a while now, and every Fedora 22 system is going to do the same. Haven't heard any complaints so far. > It's not just a visual problem, I also had problems with the launcher icon. > I removed the launcher icon from the left-hand launcher bar, then started > g-t manually from xterm. The icon appeared in the left-hand bar, and I > locked it to the launcher. Quit g-t, and clicked on this icon: it was not > able to start g-t. gnome-shell does get confused when desktop files are renamed. That is why it keeps a table to map the old name to the new.
(In reply to Debarshi Ray from comment #21) > Haven't heard any complaints so far. I'm glad there are no problems in F22 gnome-shell. But you've heard me: there are problems under Ubuntu Utopic's Unity. > gnome-shell does get confused when desktop files are renamed. That is why it > keeps a table to map the old name to the new. It's not about renaming. I've ran a "make uninstall" with the old code, patched it, compiled and installed, and tried out with a brand new user. Same problem as above. For reference, I'm attaching the output of "find /etc /usr -name '*erminal*' -mmin +15 | fgrep nome > g-t-old-files". I haven't found any leftover files that could potentially cause harm, but please take a look, maybe you find something. Of course it can be a problem with my system only and not with a fresh install, but at this moment I find it unlikely. > *shrug* I would have rather expected a reaction along the lines of "ouch, that's a problem, egmont could you please help me debug the issue and find a fix that also works on Unity?"
Created attachment 298783 [details] Potential leftover files after an uninstall && patch && install
-- 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/gnome-terminal/-/issues/7209.