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.
Make the total padding between windows equal to the padding against the
screen borders by applying just half of it on the common borders.
Adjust tests accordingly.
BUG: 469720
FIXED-IN: 5.27.6
A screen should be considered further top, and therefore more previous, only it is strictly above the other with no vertical overlap, and not if only the vertical center is higher while they are horizontally on a line. Otherwise, on a left to right setup with screens of different resolutions aligned at the edges (and thus different vertical centesr), the order will be unintuitive.
BUG: 467996
FIXED-IN: 5.27
This patch adds mechanisms to find and interact with windows to the
scripting API:
- workspace.windowAt provides a way to list the windows at a given
location on the screen.
- workspace.stackingOrder provides a list of all windows in the order
they are stacked on the screen.
- workspace.raiseWindow provides a mechanism to bring a given window to
the top of that list, making it visible above all others.
Signed-off-by: Antonio Russo <aerusso@aerusso.net>
The magic lamp literally "squashes" the window through the window icon
in the task manager.
It's assumed that there's nothing below the panel, so the magic lamp
doesn't perform any clipping.
With floating panels, it's not the case. So let's clamp the x or the y
coordinates when the window moves horizontally or vertically,
respectively, in order to ensure that the window is not visible in the
gap between the floating panel and the screen edge.
BUG: 361121
BUG: 466177
