Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
This fixes a regression introduced with a1afeded6a.
The connections were setup every the windowShown signal got emitted.
This caused effects to get multiple singals and start multiple animations
which then do not get cancelled correctly.
The incorrect behavior was most visible in the translucency effect which
did not cancel the move animation and the window stayed translucent.
BUG: 366081
Test Plan:
New test case which simulates the behavior of the translucency
effect.
Reviewers: #kwin, #plasma, sebas
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2346
Summary:
The idea behind this autotest is inspired by bug 356328 which produced
incorrect rendering results. Also it's inspired by openQA which performs
image reference comparisons.
This test case tries to go further. It creates reference images which
must match the rendering result exactly. So far the test case verifies
the start condition - kwin started and one frame is rendered with default
cursor in the middle of the screen. And it verifies the moving of the
cursor without any windows shown. Whenever the cursor moves a repaint
should be triggered and the old and new area should be properly
repainted.
To support this the test needs some minor changes in KWin:
* Scene provides a frameRendered signal - needed for waiting on frame
* Scene and SceneQPainter are exported
* SceneQPainter provides access to it's Backend, so that we get to the
backbuffer
* ScriptedEffectLoader is exported for getting a list of all scripted
effects - (we don't want fade to manipulate the rendering)
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2046
The Scripted and PluginEffectLoader perform locating all effects which
are to be loaded in a thread. When the EffectLoader gets cleared so far
the query did not get canceled. This resulted in effects maybe getting
loaded.
This problems shows on build.kde.org if the test is too fast and tears
down the Effect system while effects are still being queried.
Reviewed-By: David Edmundson
When unloading all effects we should make sure that also the ones
scheduled for loading are canceled. For this a new method clear()
is added to the AbstractEffectLoader and all inheriting classes which
clears the current load queue. For the scripted and plugin effect loader
it should also cancel the future, but that's not yet implemented.
Instead of having several hashes with data about the built-in effect,
we use a struct EffectData which contains the name, the enabled by
default state and function pointers to create, supported and check
enabled by default. There is one static vector with all the data
specified which is ordered by the BuiltInEffect enum. Thus an enum value
can be used as an index to the data.
In addition it's no longer resolved around QByteArray, but uses QString.
REVIEW: 117354
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.
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.
