This reverts commit e60f26e0ab.
Cancelling the primary selection breaks text selection in applications
such as gedit. In those apps, you can't select text neither with your
mouse nor keyboard.
BUG: 461498
These settings are highly technical, and users are likely to feel
completely lost or intimidated when they see them if they're just
browsing around. Let's add some text to explain what the heck this is
for.
This is the typical way we do this. The result looks the same in a
width-constrained window, but uses the more common FormLayout
appearance for big windows.
- obey rule of 5
- always initialize variables at declaration
- don't be needlessly explicit about things
- prefer std::array over c arrays
- don't else if after return
Currently, kwin blits the dnd icon onto the cursor image. This doesn't
work on mobile because the cursor is usually hidden there.
As a short term solution, put the dnd icon in the Scene. In the future,
it needs to be put in its own render layer.
It's somewhat popular for voice communication applications to support
Push-to-Talk. This means that the process itself expects to get all of
the system input. This behaviour albeit sound does not work on Wayland
systems.
This commit adds an option to let legacy X11 applications that assume
they will be getting all information to do so until these apps are
properly ported to the XDP GlobalShortcuts.
Right now, when `paintBackground()` is called to clear the background,
we use custom geometry and render that when the damage region isn't
infinite. Rather than using geometry, we can instead use `glScissor()`
to set the area that needs to be cleared and then use `glClear()` to
clear it.
In addition, if we have only one rect in the damage region and that rect
matches the render target rect, we can completely skip all that setup
and use `glClear()` directly.
In most places, it's actually not needed and we actually provide wrong
damage region at the moment anyway. In long term, it would be great to
drop the Window::damaged signal.
The loop in `Window::handleInteractiveMoveResize` "bruteforces" the
value for `nextMoveResizeGeom` such that the area of
`nextMoveResizeGeom` contains at least `requiredPixels`. In each loop
iteration, one or more attributes (left, right, top, bottom) of
`nextMoveResizeGeom` are selected to be moved +/-1.0 towards the value of
`currentMoveResizeGeom`. The loop terminates if either the area of
`nextMoveResizeGeom` is large enough or `nextMoveResizeGeom ==
currentMoveResizeGeom`.
The problem is that the variables compared and adjusted here are floating
point variables, and their difference may not be a whole number. Using
+/-1.0 adjustments can make the loop oscillate indefinitely around the
target value.
This commit ensures loop termination by using `qFuzzyCompare` to compare
floating point values and correctly handles the cases where adjustments
smaller than 1.0 are needed to reach the target value.
The main motivation behind this change is to let kwin use the PRESENT
extension to present output contents when using QPainter backend, so we
get PresentCompleteNotify events.
Besides that, we could potentially make X11 windowed backend forward
wl_shm_buffers to Xorg.
Currently, we use a timer to get notified when a frame is presented, but
there's a better way using PRESENT extension's PresentCompleteNotify events.
Note that we implicitly rely on the fact that EGL implementation uses
the PRESENT extension to present pixmaps, which is usually the case.
QPainter backend needs some adjustments.
Some outputs have the same EDID, which results in two connected outputs
having the same hash. To find out which config values need to be used,
also check the connector name.
Some applications do not provide a window class according to
the spec (WM_CLASS on X11, appId on Wayland), so KWin cannot
"detect" this property.
In those cases, notify the user that this is a bug within the
application (so it is not confused for a KWin misbehavior)
and also prevent setting a wrong description.
BUG: 462644
FIXED-IN: 5.27
Fullscreen windows are most likely games or videos, where the blend effect is an
annoyance that freezes the screen for a moment when a accent color change is triggered
in the background.
The main motivation behind this change is to get rid of the dependency
on EGLSurface so the order in which output layers are presented or
updated doesn't matter.
At the moment, if both the cursor and the primary layers are updated
within same frame, the read and draw surfaces in present() will be wrong
for the primary layer.
With fbos, the read and draw surfaces won't matter.
Having both selectionChanged and selectionCleared as well as
sendSelection and sendClearSelection complicates things. API users
have to connect to both signals, internally the methods have logic
to call themselves but in the end do the same as the protocols only
know send_selection.
