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.
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
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
Rational behind this change is that displayWidth and displayHeight are
X specific API calls in kwinglobals. For the future it's easier to only
rely on functionality which goes through the EffectsHandler API which
allows easier adjustments in KWin core.
displayWidth() and displayHeight() are only used to get the size or the
complete rect of all screens. This is also provided by:
effects->virtualScreenGeometry() or
effects->virtualScreenSize()
REVIEW: 116021
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*
In effects it's obvious that compositing is enabled, so specifying the
translucent element is no problem.
In tabbox a context property "compositing" is injected which decides
whether "translucent" or "opaque" elements should be used. Here the
translucent elements are only used if the Blur effect is available - for
this a new Effect::Feature Blur is introduced and in addition it is
tested whether the theme provides the translucent element.
Also the masking is adjusted to ensure that only the shadow is not
blurred.
Reason for this change is that Plasma theme seems not always to pick up
whether compositing is used when used from inside KWin. It does not cover
the Desktop Change OSD which uses PlasmaCore.Dialog and there we cannot
(yet) inject that we use compositing.
Overall I'm quite unhappy with this patch and I do hope we can fix it in
the proper place in the lifetime of 4.10 and revert this patch.
CCBUG: 311995
REVIEW: 108438
Instead of each effect, which needs to announce support, having custom
code to create a property and set it on the root window, there is now a
common API in EffectsHandler to take care of this.
The methods takes care of creating the atom if it has not already done
and set the property on the root window. Furthermore it allows multiple
effects to announce the same property without getting in conflict with
each other.
As a further convenience the property is automatically removed when the
effect is unloaded, so less things an effect author has to care about.
REVIEW: 107815
