Better map ShellClient to resource name and class

Authored by graesslin on Mar 4 2018, 4:09 PM.



The window rules dialog did not properly detect the wayland windows. So
I investigated what ICCCM writes about the WM_CLASS property (which is
the base for window rule matching) and checked how ShellClient maps to
it. Basically name and class was swapped and the reason for the
detection not working properly. As we don't have a proper name, the code
is adjusted to generate a name by using the executable name. This is
also what WM_CLASS should be filled with, according to ICCCM.

Test Plan

Rules dialog detects the name and class correctly

Diff Detail

R108 KWin
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
graesslin created this revision.Mar 4 2018, 4:09 PM
Restricted Application added a project: KWin. · View Herald TranscriptMar 4 2018, 4:09 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
graesslin requested review of this revision.Mar 4 2018, 4:09 PM
davidedmundson accepted this revision.Mar 6 2018, 11:34 AM
This revision is now accepted and ready to land.Mar 6 2018, 11:34 AM
romangg accepted this revision.Mar 11 2018, 12:50 PM
romangg added a subscriber: romangg.
romangg added inline comments.

Could you rename this variable to fileInfo or something? There is already a protected info member variable in Toplevel, that is inherited to child classes.

graesslin added inline comments.Mar 11 2018, 1:25 PM

I don't think that really matters. the protected Toplevel::info is an X11 only variable which results in a crash when using in ShellClient. So from reading code it is obvious that the Toplevel one cannot be meant as that just doesn't make sense.

Also long term plan would be to get rid of the info from Toplevel as it created various problems in the past (and protected variables are evil!)

This revision was automatically updated to reflect the committed changes.