This affects direct scanout and when the window isn't triggering desktop
repaints otherwise, like being minimized or on a different virtual desktop
or activity
KDecoration.Decoration eats all the events for the sake of keeping
an illusion of buttons being like the real ones. I didn't find any sane
way to completely turn off event filtering on that level, so instead
let's fix this MouseArea, which is a workaround, but a decent one.
AFAIK this is the last KCM in Plasma to properly support "double-click
to save" behavior. There might be others though: watch out for event
filters inside thumbnail.
If the root tile node contains only one child node, but the child node
has its own children, kwin will fail to show an outline when the user
interactively tiles the window.
On the other hand, there is no reason to have this child count check.
For what it's worth, it also prevents tiling the window if the output
only has one tile, which is odd, but a valid usecase.
BUG: 464379
Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
BUG:464509
FIXED-IN:5.27
While there's specific hardware where the IM could benefit from requesting to
be shown on a specific output, it effectively never has enough information to
choose a useful output - and the protocol doesn't allow setting a null output
to indicate that the compositor should do the choice.
To avoid showing the OSK on the wrong output, always put it on the active
output and ignore what the IM client requests.
QuickTile::setRelativeGeometry() and QuickRootTile::setVerticalSplit() or
QuickRootTile::setHorizontalSplit() can hit recursion when size
constraints start taking effect.
This change reworks how other quick tiles are resized. With the proposed
design, when relative geometry changes, QuickRootTile will notice that
and start resizing other tiles.
When QuickRootTile resizes horizontal or vertical split, it is going to
ignore QuickRootTile::relativeGeometryChanged() signals (m_resizedTile).
It prevents hitting the recursion and makes moving h/v splits more
predictable.
I do think that in order to make the tile design more robust to this
kind of bugs, it's worth splitting geometry in two kinds though - the
one that indicates the preferred geometry (implicitWidth/implicitHeight
in qtquick lingua) and the current geometry, the parent node then
monitors the preferred geometries and updates the current geometries.
BUG: 464621
Josep M. Ferrer