Summary:
So far KWin did not re-evaluate the window rules when the Client's
window class changes. Window class is the main (static) feature the rule
selection is based on. For dynamic changing mapping features like caption
KWin does re-evaluate the rules.
The reason for KWin to not evaluate when the class changes is that KWin
expects the class not to change. From ICCCM section 4.1.2.5:
> This property must be present when the window leaves the Withdrawn
> state and may be changed only while the window is in the Withdrawn
> state. Window managers may examine the property only when they start
> up and when the window leaves the Withdrawn state, but there should be
> no need for a client to change its state dynamically.
Unfortunately there are prominent applications such as Spotify which
violate this rule and do change the window class dynamically. While this
is a clear ICCCM violation there is nothing which really forbids it (may
not != must not) and nothing which forbids KWin to react on changes.
As also libtaskmanager started to react on it, it makes sense to also
hook up the required bits for window rules. After all KWin detects
changes to the window class for some time already and has the
functionality to evaluate the rules. So all there is, is one connect
which improves the situation for our users, while at the same time it
should be rather risk free. If a setup window rule breaks after this
change it's due to the client not being ICCCM compliant.
Test Plan:
I don't use any of the affected applications, so it's only
tested with the new added unit test.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16670
a04b9da61e