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
This is done by converting from the sRGB + gamma 2.2 input from clients
to linear with the color space of the output (BT.709 or BT2020 atm) in
a shadow buffer, and then convert from the shadow buffer to the transfer
function the output needs (sRGB or PQ).
If the panel is placed between two outputs, the magic lamp can pick
wrong direction and the animation will look bad.
This change improves the direction heuristic by making it analyze the
position of the center point of the screen where the window is relative
to the center point of the icon in the task manager.
The screen center is used instead of the window center in order to
properly handle edge cases such as where the window center is offscreen.
For example, if the panel is vertical (e.g. it's attached to the left
side of a monitor), the magic lamp will pick the following directions:
- if the window is to the left side of the panel, the window will be
animated so it moves to the right hand side
- if the window is to the right side of the panel, the window will be
animated so it moves to the left hand side
Without this change, the window will always move to the left hand side.
BUG: 463581
If the pointer constraint region is null, the input region must be used
instead. If the pointer constraint region is valid, it should be
intersected with the input region.
BUG: 457021
This reverts commit 7c91c4bad9.
It created regressions in some video games. After a closer look at the
pointer constraint region handling, there are some issues, but it might
be safer to fix them in master.
In meanwhile, let's revert 7c91c4bad because it breaks more things than
it fixes.
CCBUG: 457021
BUG: 469555
From the spec
On surface.attach requests to the pointer surface, hotspot_x
and hotspot_y are decremented by the x and y parameters
passed to the request. Attach must be confirmed by
wl_surface.commit as usual.
In practice, I don't think it matters that much as most toolkits use
wl_pointer.set_cursor to change the hotspot.
