Window screen edge reservation relies on Window::showOnScreenEdge()
getting called when the screen edge can't be reserved. That makes screen
edge code not easy to follow.
This change makes ScreenEdges::reserve() indicate if a screen edge has
been successfully reserved and delegate error handling to the user.
In most cases, if a screen edge has not been successfully hidden, you
just need to avoid calling hideClient() and wait until the next moment
when the window can be hidden again. Note that it differs from the
current behavior but it's for a good reason. If the panel can't be
hidden now, the panel has no idea how to handle it; only the compositor
knows when it can be hidden again.
When a window is deleted it all "set" operations should no-op.
As for the bug specifically, we have an effect that keeps the desktop
alive. If a user calls showDesktop not only do we not update the
stacking order, we also call updateLayer when the client closes this is
after the window is in the deleted state.
BUG: 470067
The Effects API has one signal screenEdgeApproaching with effects
monitoring the last signal to stay in sync.
If an Edge is destroyed whilst visible, effects currently do not get
notified and it can stay there forever.
This patch emits screenEdgeApproaching if appropriate with a factor of 0
when an edge is destroyed.
BUG: 403354
This lets Plasma itself control the position of popup windows such as
Plasma tooltips. transientPlacement() now returns the position set by Plasma
if available.
BUG: 463272
StrutsTest::testLeftScreenSmallerBottomAligned() used to pass because
one of the previous tests changes the maximize policy to maximize.
A window will be maximized only if it's larger than the maximize area
but smaller than the screen area. That's not the case and the test makes
an incorrect assumption about how X11Windows are placed.
If a shortcut has been registered several times, we can activate them several
times as well. Otherwise we just registered the first one that was introduced.
This also makes it impossible to use certain shortcuts depending on the
state.
Removes a bunch of copy-pasted code and makes the trigger gesture the mirror
of the activation. So it opens with a 4 finger swipe up and it closes with
these 4 fingers back down.
It is not intuitive that one needs to use the same gesture to activate
and deactivate an effect. Make the deactivation the inverse of the
activation instead.
Now that a single-click on a desktop in the desktop bar switches Virtual
Desktops within the Overview effect, it would be nice to have an easy way
to also trigger the prior behavior of switching and also closing the effect.
This can be accomplished by letting people double-click on a desktop to
both switch to it and also close the effect.
I found myself doing this automatically; IMO it feels quite natural.
BUG: 469307
FIXED-IN: 6.0
@teams/usability
We don't know what the current mode is, or if the display is even enabled
or whatever. Always do a modeset to be sure everything is correct
BUG: 469280
The sliding popups effect can be unloaded while there's still an active
animation for a closed window.
If that happens, the EffectsHandler::windowDeleted signal may be emitted
when the EffectWindowDeletedRef objects are destroyed. It happens after
the SlidingPopupsEffect destructor.
The sliding popups effect also has an EffectsHandler::windowDeleted
slot.
So, the problem is that m_animationsData gets destroyed first, then
m_animations is destroyed next. When m_animations is destroyed, the
deleted references will be released and EffectsHandler::windowDeleted
will be emitted. SlidingPopupsEffect::slotWindowDeleted will access
m_animationsData whose memory has been just released.
In order to prevent crashing, this change ensures that animations are
canceled while m_animationsData is still valid.
