The EffectLoader is a subclass of AbstractEffectLoader delegating all
methods to instances of:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
It's used by the EffectsHandlerImpl and replaces the complete Effect
loading mechanism we so far found in it. This also means that KLibrary
is no longer needed to load the Effects as the PluginEffectLoader uses
the KPluginTrader, which removes lots of deprecated functionality.
REVIEW: 117054
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.
A KWin::EffectPluginFactory is introduced which provides a specialized
create method and methods for the supported and enabledByDefault checks.
A set of KWIN_EFFECT_FACTORY macros are added which create a subclass
of this EffectPluginFactory following the approach from the
KPluginFactory macros. The macros only support json metadata thus the
QPluginTrader needs to be used.
The KWIN_EFFECT macros are removed as they are no longer needed.
KWin Core's loader is not yet adjusted to this change. This is a
preparation step for introducing a PluginEffectLoader.
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.
This implementation of the AbstractEffectLoader is able to to load the
scripted KWin Effects. It uses KServiceTypeTrader to find all the
candidates to load.
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
For each effect the value from the desktop file is added. This will
allow to query all effects which need to be loaded without looking for
the service files.
The functionality is to check whether the effect should be enabled by
default. It's not about whether the effect is enabled by default. This
is also needed as it's currently still taken from the plugin data.
For each effect there is an enum value. The internal mapping of effect to
create, supported and checkDefault is switched to the enum value, though
the methods for the name based variants are still available.
Some systems (e.g. openSuSE) don't install the xkbcommon header into
/usr/include/xkbcommon/xkbcommon.h (which is always in the include path),
but instead into a subdirectory, which is in the openSuSE case
/usr/include/pkg/libxkbcommon/xkbcommon/xkbcommon.h. This means that e.g.
kcm_kwinrules will not compile there since it includes input.h
REVIEW: 117069
This seems to fix the crash which could happen when closing a window. At
least the kwindowsystem unit tests no longer crash KWin (it was very
reliable before).
BUG: 332091
All the connections in EffectsHandlerImpl are replaced by the new syntax.
Where it makes sense the wrapping slot method is added as a lambda and
the slot method is removed.
REVIEW: 117076
When the Effect has to be reconfigured the configuration most likely
changed, thus we should reload it. Of course it would be possible to also
do this in each Effect::reconfigureEffect, but this would mean that the
configuration would be reloaded during startup, which we do not want.
We don't need to protect the build system against adding extra
directories in the CMAKE_MODULE_PATH This also prepares kde-workspace
to be build with a simple CMakeLists.txt in the root directory.
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.
