Summary:
So far the ThumbnailItem in TabBox mode used the window id for finding
the window it should render a thumbnail on. In the Wayland world this is
not unique. The window id could be either an X11 window or a wayland
window. We don't guarantee that there are no conflicting ids.
With the internal id we have a way to properly identify the windows, so
this element should use them.
To support this the property changed the type to QUuid and the
clientmodel also provides the QUuid. As in TabBox the way to get the
window is through the model this should be compatible for all themes.
It's tested and verified with the Breeze switcher.
For declarative KWin scripts the ThumbnailItem also provides the
AbstractClient as a property, so there should not be any script which
uses wid. If it does, this could break, but well the script should use
the intended API.
Test Plan: ctest passes, manual testing of Breeze alt-tab switcher
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D18405
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.
This is something I find unsuited, for the following reasons:
* any test in KWin for functionality set through the plugin would fail
* it's not clear what's going on where
* in worst case some code could deadlock
* KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used
The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.
But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.
To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.
To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.
This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).
As the change could introduce regressions I'm targetting 5.16.
Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18228
Summary:
7834bec52a missed to port minimize and
unminimize to dynamic dispatch. In addition to that, we don't benefit
from QMetaObject::invokeMethod so port addRepaint and addLayerRepaint
to dynamic dispatch as well.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18049
Summary:
Some effects may release the current context when they tear down, so we
have to make the current context per each unloaded effect.
BUG: 396830
FIXED-IN: 5.15.0
Test Plan: No longer able to reproduce bug 396830.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17716
Summary:
qobject_cast has several advantages over dynamic_cast:
* it works without RTTI;
* it's usually faster.
Also, when it comes to casting QObjects, qobject_cast is de facto
standard.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17427
Summary:
We use a function template, so static_cast in getMainWindows looks out
of place. Also, it's not good idea to do static_cast based on output of
isDeleted().
Test Plan: The Dialog Parent effect works.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17426
Summary:
Compositing is suspended/finished in a very hard way fashion, effect
windows are destroyed without notifying effects about it.
AnimationEffect tries gracefully release deleted windows, but because
in some cases(like when suspending compositing) a deleted window can
be already destroyed, a segmentation fault can happen.
This change adjusts the order in which effect windows and effects are
destroyed, so AnimationEffect (and other effects) cannot access dangling
pointers.
BUG: 400788
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17311
Summary:
EffectsHandlerImpl::unloadAllEffects can be very useful when writing
tests, e.g.:
auto effectsImpl = qobect_cast<EffectsHandlerImpl *>(effects);
QVERIFY(effectsImpl);
effectsImpl->unloadAllEffects();
QVERIFY(effectsImpl->loadEffect(QStringLiteral("kwin5_effect_foobar")));
but because unloadAllEffects doesn't clean up effect_order, the old
effects can be re-added back into loaded_effects when a new effect is
loaded. Such behavior can result in a segfault.
Test Plan: Existing tests pass.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17283
Summary:
EffectWindow proxies its properties from the client/deleted's
properties.
QObject::property(char*) is a slow string search. It's a loop
of string comparisons not a hash lookup!
QML's use of properties is different, there's a property cache.
It's fetched multiple times for every window in every paint of some
effects (such as blur). Hotspot shows this as a significant amount of
the render pass (X11) with nothing in kwin animating.
This patch replaces the macro that does
parent()->property("propertyName")
with a macro calling the relevant function directly without metaobjects.
This also improves type safety for future changes.
Test Plan:
Existing unit tests
Ran it for a bit
Reviewers: #kwin, graesslin
Subscribers: graesslin, zzag, broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16602
Summary:
As setDesktop was changed to "move" this left unSetDesktop non-symetric.
This replaces it with explicit API to enter/leave.
This also moves new API to the new object based API rather than still
using ints.
Where numbers are used it has been tidied up so that desktop IDs are
uint, which should be used when we have a list of desktops.
int is used only when we have either a desktop ID or NET::OnAllDesktops
(-1)
Effects API cleared up to use this and use a set of x11 IDs, which
avoids any potential complications of handling add and removes any
ambiguity with what happens if you leave all desktops and such.
Test Plan:
testVirtualDesktops passes (with pending kwayland patch)
Moving a window in the desktop grid on X11 behaves
Moving a window in the desktop grid on wayland behaves
Reviewers: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16704
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:
If the animation speed was changed, then EffectsHandler will be destroyed
and created again.
Because we don't create connections to monitor state of Wayland clients
in EffectsHandler constructor, effects like the Magic lamp won't work
after changing compositor settings.
BUG: 400240
Test Plan:
* Changed animation speed;
* Minimized a Wayland client.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16401
Summary:
In some cases, the out transition is false-triggered because we don't
react to changes in the keep-above and the full screen state.
Test Plan:
* Set the keep-above state on a window;
* Click on the desktop;
* (the window didn't "flicker")
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16270
Summary:
Getter is exposed as a property on scripted effect in a way that hides
pointers from the scripting side.
Setter is implicitly handled as a property of newly created animations
and holds the activeFullScreenEffect whilst any of them are active. Like
existing effects it remains up to the effect author to avoid the
problems of multiple full screen effects. The RAII lock pattern is
somewhat overkill currently, but it's the direction I hope we can take
EffectsHandler in next API break.
BUG: 396790
--
This patch is against the QJSEngine port, though it's not conceptually a
requirement.
Test Plan: Unit test
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14688
Summary: These two should have been in D13821 but I missed them somehow.
Test Plan:
* Ran `qdbus org.kde.KWin /Effects loadedEffects`
* Ran the following Python script
```lang=python
import dbus
bus = dbus.SessionBus()
effects_object = bus.get_object('org.kde.KWin', '/Effects')
effects_iface = dbus.Interface(
effects_object,
dbus_interface='org.kde.kwin.Effects'
)
names = (
'slide',
'pizza',
'cube'
)
supported_statuses = effects_iface.areEffectsSupported(names)
for name, supported in zip(names, supported_statuses):
print("%s: %s" % (name, supported))
```
Got the following output:
```
slide: 1
pizza: 0
cube: 1
```
Reviewers: #kwin, mart
Reviewed By: #kwin, mart
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14002
Summary: Don't use raw loop, use an algorithm from STL to copy effect pairs.
Test Plan: Effects are still working.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14004
Summary:
Don't use raw loops. Use appropriate algorithm from STL to find out
whether effect with the given name is loaded.
(also, this change deletes duplicated logic)
Reviewers: #kwin, broulik, romangg
Reviewed By: #kwin, broulik, romangg
Subscribers: broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13836
Summary:
The `role` hash key is hashed twice:
* first, when calling `contains` method;
* second, when using `operator[]`.
We can do better by using [QHash::value](http://doc.qt.io/qt-5/qhash.html#value).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: pino, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13820
Summary:
Don't use raw loops, instead, use appropriate algorithm from STL to map
a list of toplevels to a list of EffectWindow.
Test Plan:
Tested Cover switch, Flip switch, Dialog parent, and Dim inactive effect.
They all still work.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13821
Summary:
Behaviour of some effects depends on presence of active fullscreen effect.
For example, Dim Inactive effect brightens windows if there is an active
fullscreen effect. If active fullscreen effect has been changed, these effects
might need to do some setup work, e.g. schedule repainting, toggle direction
of a timeline, etc.
For what it's worth, because the Dim Inactive effect doesn't schedule
repainting after leaving Desktop Grid, windows aren't dimmed back. One
need to move mouse to trigger dimming.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13701
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
If an Effect has replaced the TabBox and wants to react on mouse events
the EffectsHandlerImpl also has an X11Filter, so we only need to make
sure the events go to that filter.
Motion: TabBox did not filter out, so events will go to the Effects
filter.
Press/Release: TabBox should not operate if Effects take the events.
The events are filtered out by Effects if there is a grab, so just
check for that and go out. Effects will take care.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7846
Summary:
So far both Workspace and Toplevel emitted signals for every property
notify event on the root window and the respective Toplevel windows. The
signals were only used in EffectsHandlerImpl to forward to the effect
system in case the property which changed is registered by an effect.
This change introduces a dedicated event filter for this which is only
created in EffectsHandlerImpl in case an X11 connection is available. It
supports a restart of the X11 system.
The signals used so far are removed from Workspace and Toplevel.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7853
Summary:
Should be when there is no more an effect which overrides the cursor,
not unconditionally.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7845
Summary:
This change introduces a dedicated X11EventFilter for the mouse
interception on X11. The filter gets created together with the start
of mouse interception and destroyed again when the mouse interception
ends. Thus we don't need to check for each event like it was the case
so far.
Unfortunately the existing methods cannot be removed (yet) as they are
still used by TabBox. Needs investigation whether this is actually
needed.
Test Plan: Xephyr+kwin_x11+Present Windows
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7842
Summary:
Several effects announce a support property atom on the root window. This
change forwards the KWin::Application's signal that the xcbConnection
changed to the EffectsHandler so that the effects can respond to it.
All effects which announce a support property connect to this new signal
and re-announce the property. In case the xcb connection died (future
XWayland crashing case) it is set to XCB_ATOM_NONE by that. In case the
xcb connection got created (future delayed XWayland startup) the atom is
set to the proper value.
In addition all usages of the support properties are guarded, so that no
nonesense actions are performed if the support property is XCB_ATOM_NONE.
Test Plan: Only compile tested as we don't have XFree KWin yet
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7761
Summary:
Read(Window)Property and deleteProperty should only operate if there is
an X11 connection available.
In addition the methods are changed to the x11 wrappers provided on the
KWin::Application as that one can support restarting XWayland in opposite
to the global methods.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7651
Summary:
KWin::displayWidth and KWin::displayHeight are bound to X11 which
doesn't make much sense on X11. In addition KWin internally knows
the overall display dimensions through the Screens singleton class.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1798
Summary:
announceSupportProperty is called from the effects on startup. It
registers the property on the X11 root window. If we would start
kwin_wayland without XWayland support this would result in a crash.
This change refactors the code so that it still registers the property,
but does not try to interact with X11. Once X11 support is available it
does the actual registering.
But this means that the effects get an incorrect atom returned. This
needs additional changes. E.g. they could also react to the
x11ConnectionChanged and register again, then they would get the proper
atom. This would also support restart of XWayland.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7475
Summary:
So far EffectsHandlerImpl directly accessed SceneQPainter::painter
through a dynamic cast. If in future the QPainter based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the painter method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7214
Summary:
So far EffectsHandlerImpl directly accessed SceneXrender::bufferPicture
through a dynamic cast. If in future the XRender based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the bufferPicture method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7207
Summary:
With qtbase 2b34aefcf02f09253473b096eb4faffd3e62b5f4 we do no longer get
events reported for the X11 root window. Our keyboard handling in effects
like PresentWindows and DesktopGrid relied on that.
This change works around the regression by calling winId() on
qApp->desktop() as suggested in the change. This is a short term solution
for the 5.10 branch.
This needs to be addressed properly by no longer relying on Qt in this
area. KWin already does not rely on Qt for Wayland in that area and is
able to compose the QKeyEvents. This should also be done on X11. It just
needs some more hook up code for xkb, but that's needed anyway to improve
modifier only shortcuts and friends.
BUG: 360841
FIXED-IN: 5.10.3
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6258
Summary:
There are a few places where KWin needs to read values from kcminputrc.
As I need to add yet another one it makes more sense to properly
structure it like in other cases and have only one kcminputrc hold in
the application. This also allows to better mock the config values in
the integration tests.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5540
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:
This is implemented through QActions following the general approach
inside KWin and not the older approach used by ScreenEdges for pointer
callback activation.
Test Plan: Extended auto test
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5263
When an application is not responding, its window is desaturated to communicate this.
Also "(Not Responding)" is added to the title bar.
Differential Revision: https://phabricator.kde.org/D5245
As pointed out by the Valgrind trace in #363224, delaying the signal causes
the EffectWindow* argument to become invalid before the connected slot is
called (this is because Qt discards only delayed signal->slot calls where
the receiver gets deleted meanwhile, not the sender and definitely not
a random argument.
If the supposed glitches really happen, they should get fixed correctly,
and for all cases (I doubt only desktop number would be involved but
not e.g. shaded or minimized states).
https://phabricator.kde.org/D5164
Summary:
This change adds global touchpad swipe gestures to the
GlobalShortcutsManager and hooks up the swipe gestures as defined at the
Plasma Affenfels sprint:
* swipe up: Desktop Grid
* swipe down: Present Windows
* swipe left: previous virtual desktop
* swipe right: next virtual desktop
The main work is handled by two new classes: SwipeGesture and
GestureRecognizer. This is implemented in a way that it can be extended
to also recognize touch screen gestures and pinch gestures.
The SwipeGesture defines what is required for the gesture to trigger.
Currently this includes the minimum and maximum number of fingers
participating in the gesture and the direction. The gesture gets
registered in the GestureRecognizer.
The events for the gesture are fed into the GestureRecognizer. It
evaluates which gestures could trigger and tracks them for every update
of the gesture. In the process of the gesture tracking the
GestureRecognizer emits signals on the Gesture:
* started: when the Gesture gets considered for a sequence
* cancelled: the Gesture no longer matches the sequence
* triggered: the sequence ended and the Gesture still matches
The remaining changes are related to hook up the existing shortcut
framework with the new touchpad gestures. The GlobalShortcutManager
gained support for it, InputRedirection and EffectsHandler offer methods
to register a QAction. VirtualDesktopManager, PresentWindows and
DesktopGrid are adjusted to support the gesture.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5097
Summary:
This change adds support for marking the OnScreenMessage as it should
skip close animation. The screenshot effect is adjusted to use the
on screen message instead of the custom effect frame.
Test Plan: Message window is not captured when taking screenshot
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D4091
Summary:
This adds support for the new on-screen-message support to the
kwineffects API and makes use of it in the colorpicker effect.
Not yet added to screenshot effect as for that we need support for
skip close animation on the on-screen-message window.
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3803
Summary:
A second interactive selection mode gets added to select a position on
the screen. This is handled by the same input event filter as for the
window selection. Just that instead of returning a window, it returns a
QPoint.
This allows to pick a point on the screen which we need to screenshot
the screen under the mouse cursor and in future for color picking.
The screenshot effect provides two new dbus methods to (interactively)
select a screen or fullscreen. This allows spectacle to screenshot the
(full) screen with still having the user in control.
Reviewers: #kwin, #plasma_on_wayland, bgupta
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3475
Summary:
EffectsHandler gains a new method to startInteractiveWindowSelection
which just delegates to the one in Platform. That way a window can be
selected and returned to an Effect.
The screenshot effect makes use of this new functionality and provides
an interactive window screenshot mode which saves to a temporary file.
Note that this is not yet the variant intended for use in spectacle.
Test Plan: Took a screenshot on Wayland
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3367
Summary:
The method is not used by any Effect and is X11 specific, thus better
remove it for good.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3298
Summary:
The VirtualDesktopGrid is ported to the new VirtualDesktop objects. The
grid consists now of QVector<VirtualDesktop*> rows and a QVector of
those rows.
This change requires to adjust the code using the VirtualDesktopGrid.
This mostly affects VirtualDesktopManger. The methods for toLeft, above,
next, etc are now all operating on VirtualDesktop with the uint variants
- if still present - only delegating to the new method. The Functor
objects are also adjusted, though mostly still providing the old API for
compatibility.
In KWin core only one now ambiguous call is adjusted (useractions) and
the desktop grid usage in EffectsHandlerImpl is adjusted. Other usages
are not yet adjusted and need porting to fully get rid of the old
uint-based API.
Test Plan: VD test still passes
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3327
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:
The implementation delegates to the Platform to perform the actual
show/hide of the cursor image.
This replaces the implementation in the zoom effect which so far
directly interacted with xfixes to show/hide the cursor. This is now
provided by the x11/standalone platform. And due to this change the zoom
effect can now properly hide the cursor on platform DRM (wayland) as
well.
Test Plan: Zoom effect on Wayland hides the cursor
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3120
Summary:
There are several effects (screenshot, zoom) which need access to the
cursor image and cursor hotspot. So far these effects used X11
unconditionally to get the cursor which obviously does not work on
Wayland.
This change adds a new class PlatformCursorImage to kwinglobals which
wraps what a cursor is (image and hotspot) and adds a new virtual method
to Platform to provide such a PlatformCursorImage. By default it's the
cursor image the Platform tracks. On X11/standalone platform this new
virtual method is overriden and provides a PlatformCursorImage from X11
using the code previously used in screenshot effect.
Screenshot effect and zoom are adjusted to use the new API instead of
X11.
Test Plan:
Zoom effect tested on Wayland, now gets the proper cursor icon.
X11 functionality not yet tested.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3093
Summary:
So far TabBox used highlight windows by passing window ids around through
an X property. This doesn't work on Wayland where we don't have window
ids for our TabBox and the Wayland windows.
This change introduces a new Effect::Feature for HighlightWindows which
the HighlightWindowsEffect provides. The EffectsHandlerImpl has a new
method to highlightWindows which it delegates to that effect if it is
loaded by invoking a new performFeature method.
The TabBoxHandler now passes the highlighting to the effects system
instead of updating the x11 property. Thus this works on Wayland and
at the same time improves the X11 side by no longer having to go through
the property protocol.
Test Plan: Verified that Alt+Tab highlights the windows on Wayland correctly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2630
