The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
Summary:
Given that wobbly windows effect takes optimized render path, it needs
to clear the clip region of about to be transformed opaque window.
BUG: 411092
FIXED-IN: 5.17.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23774
Summary:
Wobbly Windows effect is capable of animating a window when it's shown
or hidden. However, this feature has been hidden since it was added.
One needs to know how the effect works in order to enable these animations.
Therefore there's no good reason to keep these two animations because
practically no one uses them and they only add maintenance burden.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23763
Summary:
The new connect syntax has several advantages over the old syntax:
(a) Connecting with the new syntax is faster;
(b) It is compile time checked.
There are still a few places where the old connect syntax is used, e.g.
connecting to QML buttons in the Desktop Grid effect.
Test Plan:
Have been testing this patch for ~2 weeks, haven't noticed any
regressions.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, broulik, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18368
Summary:
If one wants to drag a maximized window while he or she has enabled both
the Wobbly Windows and the Maximize effect, visual artifacts can be
shown.
When the Maximize effect animates transition from maximize to restore,
some parts of the window can overshoot repaint regions(because of
wobbliness), leaving us with the visual artifacts.
To fix that, we have to take into account current scale and translation
when calculating dirty region in the Wobbly Windows effect.
BUG: 370612
FIXED-IN: 5.14.1
Test Plan: When dragging maximized windows, there are no visual artifacts anymore.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15961
Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
Summary:
When windows get added some effects grab the window and want to be the
only one animating this window. For this the grab roles exists. An
effect being notified later on evaluates the grab state and does not
start the animation.
This process failed due to being dependent on the order the effects are
loaded. Window Added/Closed are signals emitted by EffectsHandler, thus
first come, first serve. The requested effect order does not play into
it.
Due to that it could happen that an Effect which should not animate,
started to animate as the grab was still there.
This change adds the possibility to be notified whenever the window data
changes. A new signal is added to EffectsHandler which is emitted
whenever the windowData changes. The interested effects connect to it
and cancel their (just started) animation for the window.
Adjusted effects are:
* ScaleIn
* Fade
* WobblyWindows
In case of WobblyWindows an additional logical error was fixed that the
animations were only run when an effect grabbed instead of the other way
around.
BUG: 336866
FIXED-IN: 5.8.4
Reviewers: #kwin, #plasma, broulik
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3211
Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
transformed screens prevent hardware clipping
leading through filtering subquads
This requires to subquad in the painting pass
what is not supported for non rectangular
qauds ands presently aborts (in debug builds)
if any quad is transformed (as by eg. the wobbling)
REVIEW: 123733
BUG: 338972
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.
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*
The CompositingType enum turns into flags and two new values are
introduced: OpenGL1Compositing and OpenGL2Compositing.
Those new values are or-ed to OpenGLCompositing so that a simple check
for the flag OpenGLCompositing works in case of one of those two new
values. To make the generic check for OpenGL compositing easier a method
in EffectsHandler is introduced to just check for this.
The scenes now return either OpenGL1Compositing or OpenGL2Compositing
depending on which Scene implementation. None returns OpenGLCompositing.
Each effect is able to declare itself as currently being active,
that is transforming windows or painting or screen or doing anything
during the current rendered frame.
This change eliminates the hottest path inside KWin identified by
callgrind.
REVIEW: 102449
First a signal is emitted when the user starts a move/resize operation.
During the move/resize operation each geometry change emits an update signal.
Last but not least a finish signal is emitted.
This eliminates the specific method for geometry updates in drawbound resize
mode.
The signal includes the state for horizontal and vertical maximize state.
It would be better to use the enum fro, KDecorationDefines but we don't want
to depend on decorations library.
Wobbly windows is adjusted to use this new signal - it is the only effect
interested in maximize state change.
Client and Unmanaged use a signal to notify that they are about to be closed.
The EffectsHandlerImpl is connected to those signals and emits the appropriate
windowClosed signal to which the effects are connected.
All previously existing windowAdded methods are renamed to slotWindowAdded.
EffectsHandlerImpl is connected to Workspace's clientAdded signal, which is
emitted a little bit earlier than the previous direct method call. This might
change behavior.
Another signal is added to Workspace to signal that an unmanaged is added.
This has artefact potential. So if someone sees artefacts after this commit, please let me know.
svn path=/trunk/KDE/kdebase/workspace/; revision=1159203
its own directory, cleaned up the effect config macros and renamed
"MakeTransparent" to "Translucency" so that it matches its visible name.
svn path=/trunk/KDE/kdebase/workspace/; revision=921749
