Description of problem: konsole, kate and other kde apps instances are not matched by gnome-shell Version-Release number of selected component (if applicable): * gnome-shell.x86_64 3.16.2-1.fc22 * konsole5.x86_64 15.04.0-1.fc22 How reproducible: Always Steps to Reproduce: 1. Click konsole icon in dock 2. Click konsole icon in dock Actual results: After 1), a second icon appear below. After 2), a second instance opens up Expected results: Only one icon. Second click should activate the first icon Additional info: This is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1031368 Adding StartupWMClass=konsole to /usr/share/applications/org.kde.konsole.desktop fixed the issue. I am wondering, though, whether we should patch all kde apps that way... It seems gnome-shell expects WMClass to match the .desktop file name unless StartupWMClass is present. In that case renaming org.kde.konsole.desktop to konsole.desktop may help (looking at /usr/share/applications/, kde seems to be the only one with that naming convention).
There are quite a few starting to use the dbus style org.kde.foo.desktop these days, renaming is not a viable option. Lots of gnome apps are doing the same. "It seems gnome-shell expects WMClass to match the .desktop file name unless StartupWMClass is present." We need to find out if that is definitively true or not, before moving forward with adding WMClass workarounds.
Chatted a bit in #gnome-hackers irc channel on the topic. [11/11/15 07:24] <rdieter> hi, I'm researching an interaction between some kde applications running on gnome shell, https://bugzilla.redhat.com/show_bug.cgi?id=1234734 . reporter claims "It seems gnome-shell expects WMClass to match the .desktop file name unless StartupWMClass is present.", can anyone confirm this? [11/11/15 07:24] <bugbot> Bug 1234734: Fedora, unspecified, unspecified, ---, rdieter, NEW , kde apps instances are not matched by gnome-shell [11/11/15 07:24] <rdieter> fwiw, i've found at least 2 counter examples of gtk/gnome apps, gedit and totem, who's .desktop files are org.gnome.foo.desktop and those do not contain any StartupWMClass keys [11/11/15 07:28] <pbor> rdieter: could well be that gedit and totem are buggy in that regard [11/11/15 07:28] <pbor> since they have been ported to the new activation stuff and maybe missed a change [11/11/15 07:29] <pbor> I see that aday sent you here, but probably even better to ask in #gnome-shell [11/11/15 07:29] <ebassi> If the app is using GtkApplication, we use the application id to set the WM class [11/11/15 07:29] <pbor> right, so maybe gedit and totem do have org.gnome.xxx as the wm class [11/11/15 07:29] <rdieter> pbor: ok, will keep trying [11/11/15 07:30] <ebassi> rdieter: The expectation is for the desktop file to have the same name as the WM class [11/11/15 07:30] <ebassi> So if WM class is 'kfoo', the desktop file should be 'kfoo.desktop' [11/11/15 07:30] <rdieter> ebassi: ok, that's going to hit a lot of apps switching to the new org.foo.bar dbus activation style .desktop file names [11/11/15 07:31] <rdieter> unless the wm class changes to match too? [11/11/15 07:31] <ebassi> rdieter: Yes, it's expected that changing to dbus activation will also change the WM class to match the desktop file/service file name [11/11/15 07:31] <rdieter> ah, ok [11/11/15 07:31] <rdieter> ebassi: thanks! [11/11/15 07:31] <ebassi> I'm not aware of StartupWMClass being used anywhere, to be honest [11/11/15 07:32] <ebassi> Well, gnome-shell uses it, but it [11/11/15 07:32] <rdieter> ebassi: oh, so you think adding it to .desktop may not help? [11/11/15 07:32] <ebassi> is kind of too late [11/11/15 07:32] <ebassi> If we're trying to match a window to a desktop file, adding a key in a desktop file is a bit late [11/11/15 07:33] <rdieter> reporter in the aforementioned bug seems to think that it does help [11/11/15 07:33] <rdieter> ebassi: so a better long-term fix is simply fixing WM Class (to match .desktop name)? [11/11/15 07:34] <ebassi> Yes
cliff's notes version: * apparently simply adding StartupWMClass=konsole isn't good enough * patching code to set WM Class to match the .desktop name is recommended Ugh, that could end up being a lot of work :-/
<quote> [11/11/15 07:32] <ebassi> If we're trying to match a window to a desktop file, adding a key in a desktop file is a bit late</quote> The startupwmclass trick works because we are not matching wi dow to desktop, we are matching desktop to window : gnome-shell knows about the .desktop as it has it pinned :-) So we don't need the wmclass change if we don't want to (i don't think we do, it would break a lot of window matching scripts), we only need a small change to desktop files... I hope this can be achieved :-)
Nod, I was thinking the same, that adding StartupWMClass= keys could still be considered a reasonable short-term workaround, until the long-term ideal of app WM Class matching .desktop file names is achieved (if ever).
Fwiw, I found 2 gtk/gnome apps that would appear to have the same issue: gedit, totem. They both use org.gnome.foo.desktop , have no StartupWMClass= key, and their WM Class (according to xprop) are Gedit and Totem, respectively.
Re: comment #6, tested on my fedora 23 box at least
Looks like kde upstream was thinking about this today too: https://mail.gnome.org/archives/wm-spec-list/2015-November/msg00000.html
A quick update: as of Fedora 24, kf5-5.25, konsole5-16.04.3-1, GNOME Shell 3.20.3 this is still happening (and also affects dolphin, kate, ...). Workaround script: for app in dolphin kate konsole; do f="/usr/share/applications/org.kde.$app.desktop"; grep -q StartupWMClass $f || echo "StartupWMClass=$app" | sudo tee -a "$f"; done
I made a few more tests and some KDE apps seem to be behaving properly (without the workaround) e.g. KNetAttach and gwenview: it still shows properly even though e.g. WMClass is KnetAttach and file name is org.kde.knetattach.desktop I also tested the following apps to *not* be matched properly: ark, dolphin, kate, kolourpaint, PartitionManager, spectacle The difference is that the working ones have X-DBUS-ServiceName=org.kde.knetattach or X-DBUS-ServiceName=org.kde.gwenview in their respective desktop. So apparently this key is also looked at by gnome-shell. I also looked at the source code of get_app_for_window in https://github.com/GNOME/gnome-shell/blob/master/src/shell-window-tracker.c#L361 and it is clear that gnome apps will benefit from a special matching with get_app_from_gapplication_id, which is why e.g. Nautilus, gedit, totem can have a non-matching WM class. When this matching fails, get_app_from_window_wmclass is called, and this one explicitly documents using StartupWMClass (note: this invalidates comment #2 above fromm ebassi suggesting that it would/should not work) In the end, until gnome and KDE devs discuss the deeper issue, adding StartupWMClass to .desktop files seems like a pretty harmless and easy to apply/maintain workaround (even though I understand that it means many patches to create/package/upstream which is time-consuming -- maybe we could get away with only the most important ones?). What can I do to help this move along?
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is quite an old bug, can you please confirm if this is still an issue?
I don't have a Fedora+gnome at hand to test anymore. On my current system, Ubuntu 20.04.5, gnome-shell 3.36.9, plasma 5.68.0, apps 19.12.3 (old, sorry), konsole and dolphin are fine but kate cannot even be pinned ("Add to Favorites") so desktop file is not recognized I guess.