Summary:
new logout effect: it's just a slow fade in of the logout
greeter (window is usable immediately tough
Test Plan: logout greeter now fades in without setting the window opacity manually
Reviewers: graesslin, #plasma
Reviewed By: graesslin, #plasma
Subscribers: broulik, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5045
Summary:
The effect exports itself to DBus as object "/ColorPicker" and provides
an own interface "org.kde.kwin.ColorPicker".
It has one exported method to DBus "pick" which returns a QColor. When
invoked an interactive position picking selection is started. If it ends
the effect reads the color value at the picked position from the OpenGL
color buffer.
This implements T4568.
Reviewers: #kwin, #plasma_on_wayland, broulik
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3480
Summary:
The new logout design doesn't want to have the vignetting. Thus the
logout effect itself doesn't make any sense any more. All that would
still be used is the logout blur which can also be provided by the
blur effect nowadays for fullscreen windows. As the new logout is a
fullscreen window it should use that one.
The logout effect did one more thing: it kept the vignetting and the
blur once the user selected logout. Now without the vignetting this
would be weird and again doesn't make much sense any more.
So overall I think it's better to just drop the logout effect and use
blur effect in normal way. Neat side advantage: it will also work on
Wayland out-of-the-box.
Reviewers: #kwin, #plasma, #vdg
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2553
Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
The Scripted and PluginEffectLoader perform locating all effects which
are to be loaded in a thread. When the EffectLoader gets cleared so far
the query did not get canceled. This resulted in effects maybe getting
loaded.
This problems shows on build.kde.org if the test is too fast and tears
down the Effect system while effects are still being queried.
Reviewed-By: David Edmundson
This is a specialized subclass of AbstractEffectLoader to load binary
effect plugins. It used the KPluginTrader to find all candidates to load.
The loader is able to detect incorrect ABI versions through the
pluginVersion() and uses the methods exposed by the new
KWin::EffectPluginFactory to check whether the Effect is supported and
should be enabled by default.
The unit test for this loader comes with two plugins: one is able to be
loaded and provides a supported and enabledByDefault method which can be
tweaked during the test to get all the conditions we want to test for.
The second plugin uses an incorrect plugin version and thus cannot get
loaded.
