Having one state machine instead of two somehow simplifies the code and
makes it less fragile.
The new property `substate`, which replaces `thumbSource.state` still
supports imperative assignments that are so important for Drag&Drop,
and still triggers state updates. However, now a substate may not
become an active state: that behavior didn't make sense in previous
iterations, and has led to a glitch where a window won't resize during
return-to-initial animation. The glitch happened because two state
transitions were starting almost-simultaneously (and by Murphy's law in
the worst possible order, of course), and both animations were playing,
but one animation was supposed to to a property that is managed by the
other. But since QtQuick animations cache their from/to values before
they start, the dependent transition essentially didn't animate at all.
The Compositor is destroyed after the Workspace, so the placeholder has
shorter lifespan. We need to guard the destructor of EffectScreenImpl
from accessing a dangling pointer. For what it's worth, the destructor
of EffectScreenImpl was written with QPointer in mind, but it was never
added.
the existence of Window is bound to the one of workspace so it
will always be there.
We also need to check the window sizes before workspace is done
initializing,
otherwise when KWin restarts and there are maximized windows, they won't
be resized to take panels into account and will always span the full
screen.
Remember to release all resources before the wayland socket goes:
- release the seat as we give up a seat
- release the ssdManager
- release the output decoration with the output itself
Otherwise they leak and stay dangling.
When debugging something I realised that SIGTERM was always making KWin
crash like I'd never seen it crash. It turns out we are calling
QApplication::exit() on the signal handler which is highly forbidden as
the handler preempts the process altogether.
Use KSignalHandler instead which takes this issue into account.
Each screen has its own WindowHeap. So setting WindowHeap.activeClass
won't be visible on other screens.
In order to address that limitation, we could monitor
Workspace.activeClient property.
BUG: 455974
We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
It adds more test cases in OutputChangesTest, particularly swapping
outputs.
Swapping outputs is an interesting case because outputs can temporarily
overlap so workspace()->outputAt() can return wrong output and the
window is going to stick to wrong output.
re-trigger the edge *only* if the user keeps the mouse still for at
least edges()->reActivationThreshold() - edges()->timeThreshold()
so that the user has to actually keep moving.
if the user keeps moving the cursor in the direction of the edge, it
wion't continuously retrigger it
BUG:457280
the Drag attached was set to active in a taphandler which didn't
accept touch, breaking drag and drop on wayland+touch
moving the logic on the other handler makes it work everywhere
This required a bit of a magic on the WindowHeap side to store and
restore global position of a WindowHeapDelegates' window thumbnails.
An additional property bool animationEnabled on a delegate level enables
the heap to restore position without playing unneeded initial animation,
just like the heap itself.
Windows that are being dragged or already returning form a drop are
positioned higher than others on a z-stack.
BUG: 453995
..so that they always match in size, regardless of different
combinations of drag&drop and animation states.
And also fix selected property to use id-qualified access.
Currently the Workspace processes output updates as they occur, e.g.
when the drm backend scans connectors, the Workspace will handle
hotplugged outputs one by one or if an output configuration changes the
mode of several outputs, the workspace will process output layout
updates one by one instead of handling it in one pass. The main reason
for the current behavior is simplicity.
However, that can create issues because it's possible that the output
layout will be temporarily in degenerate state and features such as
sticking windows to their outputs will be broken.
In order to fix that, this change makes the Workspace process batched
output updates. There are several challenges - disconnected outputs have
to be alive when the outputsQueried signal is emitted, the workspace
needs to determine what outputs have been added or removed on its own.
The proposed way to handle unplugged gpus allows us to ensure that
removed outputs' lifetime can be extended to the moment when the
Platform::outputsQueried signal is emitted.
Besides that, it's possible to extend this code a bit further to make
sure that output updates are batched when hotplugging multiple gpus,
e.g. after resuming, etc.
