This allows to track per effect dependencies more precisely. The main
problem with a library and a comment next to it saying who needs it is
that the comment can get easily outdated.
This improves plugin loading times. As is, the main issue is the number
of builtin effects and the fact that each has a lot of translated
strings, which combined adds up to noticeable loading times. KWin itself
will never read those translated strings, it only needs two pieces - the
plugin id and whether the plugin is enabled by default.
This change adds a little helper to strip unnecessary info from metadata
files.
Since binary effects are installed in their own directory, checking
service type is redundant. Also, KPluginMetaData::serviceTypes() has
been deprecated.
Task: https://phabricator.kde.org/T14483
The main motivation behind this change is to prepare kwin for importing
kwayland-server code in libkwin.
As is, builtin effects are linked with libkwin. Some builtin effects
have wayland specific code. If we move wayland stuff in libkwin, there's
going to be a circular dependency between kwin4_effect_builtins and
libkwin targets.
This change intends to break that dependency by linking builtin effects
to kwin executable.
The main issue with that is that EffectLoader would need to discover the
effects indirectly. QStaticPlugin is used for that purpose.
Besides breaking the cyclic dependency, it makes builtin effects use the
same plugin infrastructure in libkwineffects that external effects use.
Metadata in src/effects/effect_builtins.cpp was converted in a list of
python dictionaries, which was fed to a python script that generated
main.cpp and metadata.json files.
Currently, cpp source files are included partially in effect sub-folders
and src/effects/CMakeLists.txt, which is really confusing and hard to
follow.
With this change, effect targets will be defined in their own subfolders.
This makes build files more straightforward.
Effect sub-targets are eventually merged into a monolithic
kwin4_effect_builtins target.
Another reason for modularizing builtin effects is that no two effects
can generate moc files with the same name atm even though they are in
different sub-folders. This can be potentially useful in the future, e.g.
making effects static plugins in order to decouple builtin effects from
libkwin (every effect subfolder would need a main.cpp or plugin.cpp file,
which will include the associated moc file).
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
