Summary:
The ported effect looks quite similar to the C++ version except one
thing: it works correctly when user activates/deactivates a full
screen effect, for example the Desktop Cube effect.
Other than that, there are no behavioral or visual differences.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16452
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:
Now, when the scripting effects API has all required ingredients to port
the Scale effect to JavaScript we finally can do it.
The main rationale for porting this effect to JavaScript is that
scripted effects API lets us focus more on what we want instead of
"how".
Visually, the ported version doesn't deviate from the C++ version.
Test Plan:
* Enable the Scale effect;
* Open/close a window.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16478
Summary:
There were several reasons to rewrite the Minimize Animation effect in
JavaScript: to simplify code and to get rid of full repaints. One could
say that nothing prevents us from calculating the dirty region in
postPaintScreen or postPaintWindow and it is correct, but with the
scripting effects API the dirty region will be calculated for us, so we
can focus more on "what we want" instead of "how".
Visually, the "old" effect and the rewritten one look quite the same.
Except one tiny bit: if a window doesn't have an icon in the task manager,
it won't be animated. The reason for that is the purpose of this effect is
to show where the window will be after it's minimized, if the window
doesn't have icon in the task manager, one can't click at the center of
the screen to unminimize the window.
There is one significant change, the name of the effect was changed to
"Squash". If we put this effect and the Magic lamp effect under "Window
Minimize Animation" category (or if we add some "heading" label), then
the old name and the name of the category would "conflict". The new name
was suggested by Nate Graham and it very closely describes what the
effect does. "Scale" doesn't fit this effect because while a window is
being animated, its aspect ratio is not preserved.
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16372
Summary:
The Show Paint effect is useful when debugging repaint regions issued by
effects. The only headache with it is necessity to enable/disable it.
Consider the following workflow:
* Do some change to an effect;
* Compile KWin (or the effect);
* Go to System Settings and enable the Show Paint effect;
* Test effect, check repaint regions, etc;
* Disable the Show Paint effect;
* Go to the step 1.
This workflow is really exhausting. Also, when testing repaints in a
nested compositor, things become quite messy.
Because purpose of this effect is to debug repaints (and because this
effect is not meant for daily usage), I think that's fine to change
how it's activated.
This patch improves the workflow by changing the way how this effect
gets activated. Instead of enabling/disabling it, one can just use a shortcut
to activate or deactivate the effect.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: broulik, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15703
Summary:
It's superseded by the new scale effect(D13461).
Existing users of this effect will be migrated to the new scale effect.
Depends on D13461
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13462
Summary:
The new effect scales windows as they appear and disappear.
As the the most of window animation effects, it is a monolithic effect,
i.e., if you enable scale effect, it will animate *both* the appearing and
disappearing.
The main difference between the Scale effect and the Scale in effect is
that the Scale in effect only animates windows as they appear. There is
no corresponding "the Scale out" effect, which is odd. Other points that
differentiate the Scale effect from the Scale in effect:
* it is more subtle;
* it doesn't animate the log out screen;
* it doesn't conflict with the Fade effect, etc.
... and overall, the Scale effect supersedes the Scale in effect.
{F5904947}
//Window open animation.//
{F5904948}
//Window close animation.//
{F5905283, layout=center, size=full}
//KCM.//
Test Plan:
* Enabled this effect
* Opened/closed System Settings
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, davidedmundson, fvogt, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13461
Summary:
At the moment, there is no way to tweak duration of the slide animation.
This change adds a configuration module so it is possible to change
the duration.
Test Plan:
* enable virtual desktops
* go to `System Settings > Desktop Behaviour > Desktop Effects`
and select Slide effect under "Virtual Desktop Switching Animation"
* click settings/options button and change duration
Reviewers: #kwin, #plasma, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9382
When an application is not responding, its window is desaturated to communicate this.
Also "(Not Responding)" is added to the title bar.
Differential Revision: https://phabricator.kde.org/D5245
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:
Inform the user about the path to where a screenshot got saved through a
notification. This is helpful on the one hand that the user sees that
the screenshot got saved and from a security perspective that the user
is informed when a screenshot is taken through the dbus interface. It
doesn't prevent non-authorized screenshot taking, but at least the user
is informed about it.
Reviewers: #kwin, #plasma, #vdg
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3376
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:
The new effect is based on the mouse click effect and uses the same
rendering code (this could be improved by merging them better).
Unlike mouse click there is no keyboard shortcut needed to activate:
as soon as the effect is loaded all touch points are visualized.
The visualization creates an animated circle for each touch down
position, motion and up position. The ids are tracked and each touch
id gets the same color. The first ten different touch ids get a
different color. As touch ids are stable the first finger will always
have the same color.
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2464
this effect, derived from the Maximize one, will
take the place of the manual window position
animation that Plasma tooltip are using.
this should cause less problems as animationg
positions on X is very error prone, plus it's
less jarring when the tooltip sizes changes too,
since that gets animated as well (behavior similar
to Windows7 taskbar tooltips)
REVIEW:126968
One resource is used for shader version 1.10 and one for version 1.40.
The ideas behind this change is to remove the locating of the shader
sources and also to fix that user provided shaders could be loaded
instead of the original ones (possible attack vector on Wayland).
To simplify the ShaderManager provides a new method call to load the
shader from the resource. This means the effects don't need to
duplicate the check for the shader version any more and also don't
need to duplicate the file reading functionality.
REVIEW: 126905
Basically dead code given that Plasma doesn't have a dedicated dashboard
mode anymore and also doesn't set the required window role for it to
work.
By deleting we save one string comparison for each newly opened window.
REVIEW: 125686
This change allows to include the effect_builtins.cpp into the build of
e.g. a kcm without having to link against all effects.
The use case for this is when one needs to resolve just the name of an
effect without wanting to hard code the name.
xcbutils.h has quite a few inline only implementations such as Xcb::Atom,
the Wrappers, Xcb::Window and the convenient methods. Thus there is
nothing wrong with using it from the built-in Effects.
Xcb::Atom is used in Glide and Logout Effect to get the atom. To keep the
logic of the existing code it got extended by a bool isValid() which
gets the reply and returns true if the atom is set.
REVIEW: 117587
XRenderUtils are split out of kwineffects and are an own library just
like kwinglutils is an own library.
The library gets always build and is linked in KWin core unconditionally
(as it's used in outline) and conditionally in kwineffects (PaintClipper)
and the built in effects depending on XRender build option.
There are no advantages for the effects KCM to have all the effect
config modules in one plugin.
By having a plugin per effect we can use the KPluginTrader to easily
find the configuration plugin for a given effect and load it.
To make this possible the following changes are done:
* config_builtins.cpp is deleted
* add_subdirectory is used for all effects which have a config module
* toplevel CMakeLists.txt contains the sources again for the effects
which have a config module, but effects which don't have a config
module are still included and thus the macro is still used
* plugin created for the config module, name pattern is:
kwin_effectname_config
* plugin installed to ${PLUGIN_INSTALL_DIR}/kwin/effects/configs
* desktop file adjusted to new plugin name and keyword removed
* desktop file converted to json as meta data and no longer installed
* Uses K_PLUGIN_FACTORY_WITH_JSON
* Macros for config are dropped from kwineffects.h
REVIEW: 116854
KWin already has a de facto OpenGL 2 dependency through QML. Combined
with the fact that the OpenGL 1 backend is basically unmaintained and
also unused, it's better to remove it for the new major release.
This change includes:
* Removal of cmake option KWIN_BUILD_OPENGL_1_COMPOSITING
* Removal of KWIN_HAVE_OPENGL_1 compile option and all code
ifdef'ed with it (partially removal of if-else constructs)
* Removal of CompositingType::OpenGL1Compositing (flags are kept
as a core flag should get introduced)
* Driver recommendation for OpenGL1Compositing changed to XRender
(should be evaluated whether the drivers can provide GL2)
* Removal of configuration option "GLLegacy"
* Removal of fooMatrix function in kwinglutils
* Removal of ARBBlurShader
* Removal of legacy code path in GLVertexBuffer
* Removal of GLShaderManager::disable
* if-blocks with ShaderManager::instance()->isValid() removed
REVIEW: 116042
It's no longer needed as there won't be a KWin version specific to
Plasma Active. We want to have runtime adjustments of all parts in
the next version of Plasma.
REVIEW: 116563
As all effects have always been compiled into the same .so file it's
questionable whether resolving the effects through a library is useful
at all. By linking against the built-in effects we gain the following
advantages:
* don't have to load/unload the KLibrary
* don't have to resolve the create, supported and enabled functions
* no version check required
* no dependency resolving (effects don't use it)
* remove the KWIN_EFFECT macros from the effects
All the effects are now registered in an effects_builtins file which
maps the name to a factory method and supported or enabled by default
methods.
During loading the effects we first check whether there is a built-in
effect by the given name and make a shortcut to create it through that.
If that's not possible the normal plugin loading is used.
Completely unscientific testing [1] showed an improvement of almost 10
msec during loading all the effects I use.
[1] QElapsedTimer around the loading code, start kwin five times, take
average.
REVIEW: 115073
* a copy of the blur shader to become a copy of the background contrast effect
* contrastshader actually doing the light modification
* don't expand/shrink the area
Most effects had a "collection" for one action. We don't need the
action collection, all it was used for is setting the object name.
With the removal of KActionCollection the effects do not need to link
XmlGui any more, though the dependency is still pulled in through
plasma.
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
As KWin indirectly uses Qt's OpenGL through QtQuick we need to ensure
to not mix OpenGL and OpenGLES. So we have to built KWin only against
OpenGL if Qt is built against OpenGL and we have to built KWin only
against GLESv2 if Qt is built against GLESv2.
This means the kwin_gles binary is no more. There is only kwin which
either links GL or GLESv2.
