Method no longer virtual and only implemented in AbstractClient.
The implementaton works in a generic way nowadyas.
Added an autotest for the basic packTo behavior for packing against
a screen border. Packing towards other clients still needs adjustments
in the Placement code.
The signals operate on AbstractClient nowadays, so we can have one
implementation for both Client and ShellClient.
Only X specific connections are only done for Client.
So far only moving through useractions menu is possible and only through
cursor control (mouse events are lost).
A basic first autotest is added to validate the moving of Windows.
Sync related code is split out into dedicated virtual methods so that
Client can provide the X11 specific implementation. General handling,
though is completely in AbstractClient.
Implementation is moved to abstract_client.cpp as so far events.cpp
does not have any code from AbstractClient.
This includes moving the electricMaximizingDelay from Client to
AbstractClient.
The implementation of positionGeometryTip is X specific, we need to
figure out whether that one makes sense for Wayland. Given that, let's
have it virtual to ease the transition of code which calls it.
The implementation calls a virtual doStartMoveResize() which allows
Client to do it's X11 specific tasks (creating moveResizeWindow, grabbing
input).
The base implementation is no longer virtual.
Includes moving the m_cursor and Qt::CursorShape cursor() method to
AbstractClient. In addition AbstractClient now emits a signal whenever
the shape changes allowing Client to react on it (update the low level
cursor) and also hopefully the Wayland Backends to react to it, so that
we have the cursor.
a) When a group-transient is modal, it still needs to be
on the current or all virtual desktops if *any* of the
blocked clients is
BUG: 354090
FIXED-IN: 5.5
b) ignore demanded virtual desktop for transients. Notably modal transients
should appear where their parent is, and not drag that around. All others
also better show up above their parent and not a distant virtual desktop
REVIEW: 125758
During tearing down the WaylandServer it's possible that ShellClients
are getting unmapped. For them make sure that they don't call into
the no longer existing Workspace.
The problem we had was closing a glxgears through an Aurorae theme
crashed KWin inside QtQuick.
This test case simulates the sequence:
1. starts glxgears
2. wait till we have a Client for it
3. send mouse move to guessed close button position
4. send mouse press/release at that position
5. verify the window is closed
6. verify glxgears exits
With the given commit reverted this crashes, with it in place it passes.
Please note: on CI it might fail as glxgears is not yet installed. [1]
Also we cannot enforce using Aurorae from the test yet, though on
the CI system it should get picked automatically as no other deco
plugin should be installed.
[1] Sysadmin ticket already created
Apparently it's not allowed to set root context properties multiple
times. If one goes to systemsettings, opens effects kcm, closes it
and opens it again it crashes due to setting a context property with
same name again.
This change eliminates the need for the context property by modifying
the property of the QML objects directly.
BUG: 354164
BUG: 351763
FIXED-IN: 5.4.3
REVIEW: 125737
It was broken on so many ways, it's unbelievable:
* action was read but did nothing
* config was saved into a different file than read from
REVIEW: 125701
CCBUG: 331841
Removes the ElectricAction for ShowDashboard and the relevant code
in screenedges and the KCM.
Also a leftover in the glide effect.
REVIEW: 125700
BUG: 353928
Our decoration is deleted using deleteLater() and that might cause access
to the bridge. Given that we also need to deleteLater() the
PreviewBridge.
To do so the PreviewBridge is no longer directly exposed to QML, but
in a wrapper object which holds the bridge as only element.
BUG: 344278
FIXED-IN: 5.4.3
REVIEW: 125724
This changes how we synchronize through vsync. We use a mutex and a
wait condition to synchronize the threads. When presenting the frame
our main gui thread blocks and will be woken up by the vsync event
(or a timeout of max 1 frame time slot). In order to minimize the
blocked time we use the blocksForRetrace functionality from the GLX
compositor.
Given this change we no longer need to tell the compositor that we
are swapping the frame, it's blocked anyway. Also we don't need the
failsafe QTimer anymore.
With this change applied on a Nexus 5 it's succeeding the "Martin
tortures phone test". It doesn't tear anymore and has a smooth
experience.
I'm rather disappointed by the fact that we need to block in order
to get vsync. This means Android/hwcomposer is as bad as GLX. So
much for the "Android stack is so awesome", in fact it's not. Anybody
thinking it's awesome should compare to DRM/KMS and especially atomic
modesetting. Yes it's possible to present frames without tearing and
without having to block the rendering thread.
Reviewed-By: Marco Martin and Bhushan Shah
The check whether Workspace is created is not sufficient. There's a
time when Workspace is already created but Compositor not ready yet
and where we can hit this code path.
