kwin/effects/slidingpopups
Martin Gräßlin fb69b791a1 Ensure that all Effects honour the grab roles correctly
Summary:
When windows get added some effects grab the window and want to be the
only one animating this window. For this the grab roles exists. An
effect being notified later on evaluates the grab state and does not
start the animation.

This process failed due to being dependent on the order the effects are
loaded. Window Added/Closed are signals emitted by EffectsHandler, thus
first come, first serve. The requested effect order does not play into
it.

Due to that it could happen that an Effect which should not animate,
started to animate as the grab was still there.

This change adds the possibility to be notified whenever the window data
changes. A new signal is added to EffectsHandler which is emitted
whenever the windowData changes. The interested effects connect to it
and cancel their (just started) animation for the window.

Adjusted effects are:
* ScaleIn
* Fade
* WobblyWindows

In case of WobblyWindows an additional logical error was fixed that the
animations were only run when an effect grabbed instead of the other way
around.

BUG: 336866
FIXED-IN: 5.8.4

Reviewers: #kwin, #plasma, broulik

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D3211
2016-11-07 11:45:09 +01:00
..
CMakeLists.txt [effects] Drop the .desktop files for the BuiltIn Effects 2014-04-28 13:52:43 +02:00
slidingpopups.cpp Ensure that all Effects honour the grab roles correctly 2016-11-07 11:45:09 +01:00
slidingpopups.h [effects] Adjust SlidingPopups to new windowShown and windowHidden signals 2016-07-13 10:49:00 +02:00