Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
Summary:
The glide effect tried to not animate any window the SlidingPopups
effect animates. But it detected that in a very crude way. It announced
the KDE_SLIDE atom and checked for windows having that property set.
This has a few disadvantages:
* KWindowEffects::isEffectAvailable gets confused as an effect announces
support for SlidingPopups which doesn't provide SlidingPopups
* The approach can only work for X11 windows
* The approach causes X11 usage in the ctor
With this change the GlideEffect implements a slot for
EffectsHandler::windowDataChanged to detect that the SlidingPopupsEffect
grabbed the window. The X11 atom interaction is removed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3296
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
Removes the ElectricAction for ShowDashboard and the relevant code
in screenedges and the KCM.
Also a leftover in the glide effect.
REVIEW: 125700
BUG: 353928
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
This removes all the hacks to add kwin4_effect_ to the name of the Effect
and adjusts the desktop files of the effect configuration's parent
component.
Note: the scripted effects still start with kwin4_effect_ prefix.
REVIEW: 117367
All KCMs and KWin core use the BuiltInEffects namespace to find and
interact with the effects. There is no information left in the desktop
file which are of usage. Thus they can be removed.
So far the effects could just use the connection() and rootWindow()
provided by kwinglobals. Thus an internal detail from KWin core is
accessed directly.
To be more consistent with the rest of the API it's wrapped through the
EffectsHandler and with a convenient method in Effect.
The connection() is provided as xcbConnection() to free the very generic
name connection which could create confusion once we provide a wayland
connection to the Effects.
The rootWindow() is provided as x11RootWindow() to indicate that it is
for the X11 world.
REVIEW: 117597
This method replaces the X-KDE-ORDERING property in the Effect's desktop
files. This change is a preparation step for integrating the new Effect
Loader which doesn't read the ordering information. Thus it needs to be
provided by the Effect itself so that the EffectsHandler can properly
insert it into the chain.
Also for the built-in Effects on the long run it doesn't make much sense
to install the desktop files. And binary plugin effects will migrate to
json metadata which also doesn't have the KService::Ptr. Thus overall it
simplifies to read this information directly from the Effect.
Affected effects
* Blur and Contrast Shader to get atom name
* Glide effect for the slide atom
* startupfeedback for cursor size - read from config now and cached
* showfps used an xsync, replaced by flush
* logout effect for creating hack items
REVIEW: 116828
Most is just switched to the ::read(). That should be enough for all the
Effects which have a KSharedConfig::Ptr underneath. If not we just need
to find a good place to put the reload.
Instead of using EffectsHandler::sendReloadMessage we generate the dbus
interface in each plugin and call the reconfigure slot directly. That way
it's more type safe and we don't need to link kwineffects from the
configs.
REVIEW: 116875
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
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
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
This method can be used to get the animationTime in case a configuration
class generated through KConfigXT is used. In general the configuration
stores the magic value 0 for a property "duration". This magic value
indicates that a hard-coded default value should be used.
So the common logic to test the stored value for 0 and then either pass
the stored value or the default value to animationTime is encapsulated
in this method in a generic way.
A MyEffect can use it in the following way:
animationTime<MyEffectConfig>(200);
BUG: 310646
FIXED-IN: 4.10
REVIEW: 107460
