It is automatically called (and documented as such) by KCModule
after the constructor is run.
This avoids calling a virtual method from the constructor.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
None of the features it adds ontop of `QComboBox` are used.
Allows to drop the dependency on KCompletion.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
Because the GLRenderTarget and the GLVertexBuffer use the global
coordinate system, they are not ergonomic in render layers.
Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is
an interesting api design choice too. Scaling is a window system
abstraction, which is absent in OpenGL or Vulkan. For example, it's not
possible to create an OpenGL texture with a scale factor of 2. It only
works with device pixels.
This change makes the GLRenderTarget and the GLVertexBuffer more
ergonomic for usages other than rendering the workspace by removing all
the global coordinate system and scaling stuff. That's the
responsibility of the users of those two classes.
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.
Doe to 1a0031c08a3b41458eb5bf2097b4cd6452ba3d09 we no longer require json metadata to be embedded.
Also we did not use the metadata anywhere, except for finding the correct plugin.
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 GLTexture class is forward declared and the ShowFpsEffect class has
a QScopedPointer<GLTexture> field. We either need to include the
kwinglutils.h header file or add a destructor that does nothing and
define it in the cpp file, where kwinglutils.h is included.
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.
