Summary:
The idea behind this autotest is to verify that different window
open/close animation effects behave similarly.
Currently, we just check whether Fade/Glide/Scale effect tries to animate
the appearing or the disappearing of toplevels. In the future, the
autotest will be extended to verify that there are no conflicts between
those three effects and the Login/Logout effect, etc.
Test Plan: Ran the test, found a bug in the Fade effect, fixed it.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17526
Summary:
Currently, we have three effects that can be used to animate the
appearing of toplevel windows(fade, glide, scale) and one can enable
all three of them, which seems to be wrong. It doesn't make sense to have
glide and scale effect enabled, for example.
We couldn't put all three effects into an exclusive group before because
the fade effect animates not only toplevel windows but also popups. So,
if all three effects are in an exclusive group and you enable glide effect,
for example, then tooltips and other popups won't be faded in/out.
This patch splits the fade effect into two: the first effect (called Fade)
animates toplevel windows and the other one (called Fading Popups) animates
popup windows.
Test Plan:
Have been using the Fading Popups effect in combination with the Scale
effect for a couple of days. Haven't noticed any significant differences between
the new combination (Fading Popups + Scale) and the old combination
(Fade + Scale).
Reviewers: #kwin, #plasma, #vdg, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16836
Summary:
This means that if one opens/closes a window whilst present windows (for
example) is active we don't have two effects meddling with the opacity.
Like glide and scale this disables if it's invoked during an active full
screen effect, but it does not cancel animations that are running when a
full screen effect is launched.
Test Plan:
Windows still fade normally as before
Ran sleep ; dolphin with present windows / cube
Present windows fades windows itself so it's hard to see any difference
But it's more technically correct
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15933
Summary:
The appearing of the logout screen is animated by both the Fade effect
and the Logout effect. The former should not animate the logout screen
because that's the job of the latter.
Test Plan:
Clicked the shut down button, the log out screen smoothly faded in.
Clicked the cancel button, the log out screen instantaneously disappeared.
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14582
Summary:
For Wayland windows we can have a sequence of window unmapped
(windowHidden signal) followed by a windowClosed way later when the
application quits. This is for example the case with menus.
The result of this was that the fade out animation triggered when the
application quit showing all the already closed menus again.
This change implements a windowShown and windowHidden handler and
triggers the fadeIn/Out animation on it. If the window gets shown
again the existing fadeOut animation gets cancelled, so that it can run
again.
If a window gets closed for which a fade out animation has been run
already, it's not triggered again, thus ensuring that we don't see
zombie windows.
CCBUG: 372622
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3419
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
with 4 instead of just altering the default value
It seems the value is actually written for some ppl.
Worse: former patch didn't actually work as expected
anymore
CCBUG: 321897
compensated by a QuartOut shape, this keeps the
effect alive while the sheet or similar effects run
without much visual stretch
Covers issue until there's AnimationEffect::determine()
CCBUG: 321897
semi Fixed in 4.11.2
REVIEW: 111798
Ensures that we can access the minimized property in Effects
which want to not animate a closed, minimized window.
Make use of it in the Fade Effect Script to not fade out a
minimized window which would mean showing the actual not
visible window.
BUG: 303891
FIXED-IN: 4.9.0
REVIEW: 105647
Our first effect written in JavaScript to replace an existing C++
effect. Fade effect has been chosen as it has shown to be problematic
in the past and would have needed a migration to AnimationEffect anyway.
