Remove legacy Wine hack-around from rules rc.

Authored by hein on May 23 2018, 11:25 AM.



After we improved our StartupWMClass handling we worked with Wine
in 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.


Diff Detail

R120 Plasma Workspace
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
hein created this revision.May 23 2018, 11:25 AM
Restricted Application added a project: Plasma. · View Herald TranscriptMay 23 2018, 11:25 AM
hein requested review of this revision.May 23 2018, 11:25 AM
davidedmundson accepted this revision.May 23 2018, 11:29 AM

[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"

This revision is now accepted and ready to land.May 23 2018, 11:29 AM
hein updated this revision to Diff 34702.May 23 2018, 11:45 AM

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

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.

hein added a comment.EditedMay 23 2018, 12:35 PM

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.)

hein added a subscriber: bshah.May 23 2018, 12:36 PM
hein requested review of this revision.May 23 2018, 12:43 PM
broulik accepted this revision.May 23 2018, 4:23 PM

kcmshell5 still shows proper icon and some Wine apps I tested also work fine, however wine notepad is just as broken as before

This revision is now accepted and ready to land.May 23 2018, 4:23 PM
This revision was automatically updated to reflect the committed changes.