Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.
While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.
Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.
Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.
Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.
Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.
We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
The following click behaviors are defined:
* Switch desktop and activate window [default]
* Switch desktop only
The former emulates the previous default of activating clicked windows
using the Present Windows effect. The latter introduces a new mode where
the clicked window is not activated, allowing the user to select a
virtual desktop without worrying about disrupting the last active
window.
The configuration toggle that controlled the use of the Present Windows
effect has been subsumed into the first click behavior, i.e., if the
effect is enabled, it will be implicitly triggered.
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:
Use windowFrameGeometryChanged rather than windowGeometryShapeChanged
because we are interested only in frame geometry changes.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26908
Summary:
Lots of red, does the same thing in a simplified way avoiding creating a
real window and having to hack round it.
Test Plan: Click add and remove, remove button disables appropriately
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: meven, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26381
Summary:
Won't make things go much faster since everything that was
being passed by value is refcounted but still const & is a bit faster
than refcounting
For shared pointers instead of adding const & we move them into the
destination variable saving some cpu usage but at the same time making
clear the pointer is being stored by not being const &
Reviewers: zzag
Reviewed By: zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25022
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
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:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
Currently, effects like Maximize, Slide Back have problems with setting
WindowForceBlurRole. They store previous state of WindowForceBlurRole.
This is wrong. Instead they should either ignore previous state of
WindowForceBlur or refcount forced role.
There's no need for refcounting right now. For example, if several effects
force blur or background contrast, they are most likely in a conflict.
Please notice that the Desktop Grid effect uses the Present Windows
effect only to calculate transformations.
Some other problems with the code that sets WindowForceBlurRole:
* Maximize effect stores previous state of WindowForceBlurRole only
for one window. It ignores the fact that there could be several
active maximize animations;
* Desktop Grid/Present Windows/Slide back don't clean after themselves.
So, after using those effects for good amount of times, memory usage
will bump.
Test Plan:
* Enabled blur for Konsole
* Maximized Konsole
* Activated Present Windows
* Activated Desktop Grid
* Raised another window(to trigger Slide Back)
Reviewers: #kwin, fredrik
Reviewed By: fredrik
Subscribers: fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13479
Summary:
All effects which use a (pointer) screen edge now also support the touch
screen edges. These are:
* Cube (cylinder, sphere)
* DesktopGrid
* PresentWindows (current, all, class)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5269
Summary:
This reverts commit 14d1fdf63f.
The zoom effect is definitely the wrong way, it's broken (can be
triggered without moving the mouse, expands windows outside of their
allotted area (looks like broken sizing/placement), isn't animated so
feels very choppy, isn't using well-known highlight semantics), the
result is that it feels unnatural and jarring. To be honest, when I
looked at it, I was looking for a bug in the code, e.g. margins not
being taken into account. It didn't come up in me that this could be
wanted behavior, until I read the code.
As to the original commit message: The highlight is useless for this
case, as any window can be dragged or activated, highlighted or not.
What *could* work is to somehow intensify the colors, but that again
would have to be animated, and play well with the ongoing desktop-zoom
animation, the mouse pointer location changes relative to the window, so
it's really complex to get right. I thought of this for a while, I don't
think the complexity that has to be implemented is worth the benefit,
because, what does highlighted really mean here? "window is under the
mouse" isn't a useful metric, as we don't know if the user is changing
desktops or rearranging windows, and "window under mouse" changes
depending on the zoom level, "window can be dragged or activated" also
isn't a useful metric, as I can do that with any window, anyway.
Test Plan: Tested with patch applied, desktopgrid windows don't jump around anymore.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1209
To indicate that the window is "active" ie. can
be dragged or activated (like in present windows)
There was either a bug or a forum post complaining
about the inability to activate windows from DG
They're only traversed and QHash is unordered - so
the worst container. Also we have complete control
over the maintained class, so we can just keep the
mapped EffectWindow there
the (old) button effect windows used to be unreferenced
with the re-invocation of the effect. because we stopped
deleting/recreating the window, this approach failed and
the effect window was never deleted.
Unreferencing the window at proper occasion (see new hide
location) coked up - guess what - the exact same "texture is
junk" issue as for the QtQuick close button in present windows...
So we resort to the exact same stupid "hide by moving" solution
as we have there.
BUG: 348577
FIXED-IN: 5.4
REVIEW: 124136
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.
With the removal of BoxSwitch all effects which want mouse events use the
fullscreen input window. The available functionality is too complex both
in EffectsHandler and in the Effects.
With this change only fullscreen input windows are supported and all
effects share the input window. This means there is at maximum one input
window. This simplifies the code in the Effects as they don't have to
keep track of the window they created any more. In EffectsHandler it
means that only one window needs to be created, destroyed and raised.
Also it means that we can properly react on screen size changes which had
been ignored in the past. Also quite some roundtrips to X are no longer
needed as we do not need to query the window geometry when creating the
input window.
REVIEW: 110156
The ownership for virtual desktops is moved from Workspace into a new
VirtualDesktopManager. The manager is responsible for providing the count
of virtual desktops and keeping track of the currently used virtual
desktop.
All methods related to moving between desktops are also moved from
Workspace to the new manager, though all methods related to Clients on
Virtual Desktops remain in Workspace for the time being. This is to have
the new manager as independent from KWin core as possible.
An rather important change for the handling of virtual desktops is that
the count and the id of a desktop is now an unsinged integer instead of
an integer. The reason for that is that we cannot have a negative count
of desktops as well as it is not possible to be on a desktop with a
negative identifier.
In that regard it is important to remember that a Client can be on a
desktop with a negative identifier. The special value for a Client being
on all desktops is handled by using -1 as a desktop. For the time being
this is not adjusted but instead of comparing the virtual desktop ids one
should prefer to use the convenient methods like isOnDesktop and
isOnAllDesktops. This would allow in future to internally change the
representation for on all desktops.
The supportInformation is extended to also read the properties
on all effects. In addition each effect can be queried just for
itself through D-Bus, e.g.:
qdbus org.kde.kwin /KWin supportInformationForEffect kwin4_effect_blur
All effects are extended to provide their configured and read
settings through properties. In some cases also important
runtime information is exposed.
REVIEW: 105977
BUG: 305338
FIXED-IN: 4.9.1
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
The KWin::TimeLine class was only a small wrapper around QTimeLine
without adding anything to QTimeLine what is not present in QTimeLine.
The initial idea was to make it possible to provide more curve shapes.
This is now obsoleted by Qt shipping more useful curves with QTimeLine.
So let's clean up a little bit and use QTimeLine directly instead of
the small wrapper.
All effects are adjusted to use QTimeLine directly.
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.
Since the EffectFrames have been moved into KWin core nothing in the
Effects lib actually used Plasma. The only remaining method is moved
to core as it's not used in the Effects. The Effects itself still
link against Plasma, so nothing changes for them.
The Plasma includes in the kwineffects header seemed to pull in
quite some additional headers, so the includes in some effects have
to be adjusted (most often KConfigGroup). This should speed up the
compilation of the library and the effects.
* on drag start rearrange windows in old desktop
* while moving having window attached to mouse cursor
* on drop rearrange windows in new desktop
svn path=/trunk/KDE/kdebase/workspace/; revision=1049583
