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
Move some generic properties to the OutputLayer class and add a cursor
layer getter in the RenderBackend class. That allows us to get rid of
some code duplication. And we could use this work to move more cursor layer
code from backends to Compositor.
Sending an axis event for every high-res scroll wheel movement was
causing excessive scrolling on clients that expect low-res (discrete)
scroll events.
Signed-off-by: John Brooks <john@fastquake.com>
At quick glance, it doesn't seem like there's any benefit from storing
the shadow elements as pixmaps. It saves us some QImage <-> QPixmap
conversions too.
Creating views is the main thing blocking quick effect activation.
Rather than blocking until everything is created, we can use
QQmlIncubator so we create views asynchronously. This allows KWin to do
other things while views are being created. This is mostly relevant for
multiscreen setups where we create a view per screen.
If there's windows and we're not searching, we don't need the
PlaceholderMessage. So only create it when we actually need it to reduce
the time needed to activate the effect.
We don't need the features of Repeater here and can instead just use an
Instantiator, which allows us to use asynchronous creation for the
window delegates, reducing the time needed to activate the effect.
There are some performance differences between X11 and Wayland. Desktop
systems are mostly unaffected by them, but laptops suffer a bit.
On Wayland, kwin always does double buffering. This is great for
reducing latency and avoiding tearing, but if the gpu can't keep up with
the work, you're going to see stuttering.
Another issue is that in order to reduce latency, we need to have very
good frame stats. At the moment, kwin records only cpu render time, but
we also need to record the gpu time. We've already done some work in
this area, but it's most likely Plasma 6 material. (plasma/kwin!1163)
In the meantime, let's change the default latency policy to "Force
smoother animations." It's going to improve frame rate. If people care
about latency, they can change latency policy in system settings; the
option is still there.
CCBUG: 452119
Main reason to support this old interface is because this is the only
protocol chromium (and effectively all electron app) that supports.
The protocol itself very similar to text-input-v2 with some minor difference.
So not hard to support by just duplicate some existing code. There might be
some unclear protocol design issue if kwin need to support multiple SeatInterface,
but for now it should be ok to assume there is only one seat.
Tested using fcitx5 against weston-editor and chromium with flag
--enable-features=UseOzonePlatform --ozone-platform=wayland
--enable-wayland-ime
The window rules kcm uses lower-case window class and role, but kwin can
use window class and role with other casing, which will break the ExactMatch
match rule.
BUG: 464190
