After we improved our StartupWMClass handling we worked with Wine
in https://bugs.winehq.org/show_bug.cgi?id=32699 to get them to add
StartupWMClass=foo.exe keys to the .desktop files they generate,
since they have foo.exe in WM_CLASS.
This old rule short-circuits the StartupWMClass handling prevented
this from actually working on our side.
BUG:393787
| No Linters Available |
| No Unit Test Coverage |
[12:26] <d_ed> Sho_: what happens with this patch and an old wine?
[12:28] <Sho_> d_ed: the result should be the same. because ManualOnly is a vestige from old libtm, but the new libtm applet actually has no UI to manually set a launcher. so in both cases it will return an empty launcher URL. previously because ManualOnly forced this, now because it wouldn't fine anything for "Wine"
It turns out Wine installs its Windows Program Loader as a wine.desktop
file, which is useful to "Open With" .exe files, but means if Wine doesn't
set a WM_CLASS that we can find a .desktop file by StartupWMClass for, we
map windows to this wine.desktop, which leads to a crappy UX.
This wine.desktop file thankfully sets NoDisplay=true, so let's expand
on our cautious earlier decision to check for NoDisplay only when looking
inside .desktop files, to also check NoDisplay when matching by .desktop
file name.
The StartupWMClass handling still doesn't check for NoDisplay, so an app
dev can force to a NoDisplay .desktop by setting StartupWMClass (in keep-
ing with the earlier decision to trust StartupWMClass as an overriding
directive).
The Rewrite Rules engine similarly doesn't check for NoDisplay so you
need to know what you're doing when writing rules. It didn't seem good
to restrict it in some way, since the entire point of Rewrite Rules is
to be able to override compiled code behavior.
I can't see any downside to checking NoDisplay for the .desktop file
name match part, since those are the "vanilla case" blocks where we
try to associate windows with apps on the menu.
I was a bit worried my latest change could break the case of kcmshell setting KCM .desktop files (which are NoDisplay), but on X11, this is done via a window hint we evaluate directly in XWindowsTasksModel (bypassing TaskTools) and in any case it's set to a path, which windowUrlFromMetadata handles first in an earlier block. This path handling block is what it hits with the appId on Wayland, so it works fine there too. (Thanks to @bshah for getting me Wayland debugging data.)
kcmshell5 still shows proper icon and some Wine apps I tested also work fine, however wine notepad is just as broken as before