There are behavior differences between QFutureInterface and QPromise.
The QFutureWatcher::finished() signal will be emitted in both cases
when the promise reports results or it is canceled.
Both frameSize and clientSize are rounded to integral XNative units.
So their difference must also be rounded to integral XNative units.
Otherwise we get cycles of rounding that can cause growing window sizes.
BUG: 481460
Otherwise it's theoretically possible to create a new ClientConnection
object for the zombie wl_client when its resources are being destroyed.
For example
- process early wl_client destroy notification
- the ClientConnection objects gets removed from the client list in Display
- process wl_resource objects getting destroyed
- if some code calls display->getConnection(zombie_client), it's going to
reintroduce the client in the client list
- process late wl_client destroy notification, it's going to destroy the
original and the clone ClientConnection object
This change prevents reintoducing a clone client object, by keeping the
original for a bit longer until it's actually destroyed. In the future though,
it would be great to kill the client lists in Display and ClientConnection,
and just use `static_cast<ClientConnection *>(wl_client_get_user_data())`.
If the pointer is constrained, the screen edge may push the cursor back,
which will work not as expected. It's also undesired to trigger the screen
edge while the pointer is constrained by some surface, in general.
As Wayland doesn't have a warp event yet, before this commit, warps were
dealt with like normal absolute motion events. This trips up games though,
which don't deal with actual absolute motion events well. As a solution
to that, until an actual warp event is a thing, we send a motion event with
a position + a relative motion event with no motion
BUG: 458233
CCBUG: 482476
Consider a window with the size of 50x100 and the titlebar height of 36px.
The maximum number of visible titlebar pixels is 1800, but the
titleBarRect() function reports 3600 instead, which is completely wrong.
Since the reported number of required visible pixels is wrong, the window
geometry constraining logic is mistriggered and it's possible to move the
window only by 1px.
The pointer should cross a corner as soon as the movement in the barrier
zone exceeds barrierWidth. Previously horizontal and vertical movements
were separately considered, which made corners harder to cross compared
to edges even when the separate corner barrier was disabled.
CCBUG: 483651
QuickEffect::setDelegate is exposed QML API.
The lifespan of assigned objects is therefore managed by the QML engine,
and we should be watching for deletion not actually deleting it.
X11 did not have a requirement that apps needed keyboard focus to update
a clipboard. Apps could copy things on click. With context menus and
grabs there can be no active window at this point.
Kwin tried to retrofit a requirement, which doesn't work in all cases.
Whilst there are security implications of reading a clipboard there are
no security issues about pushing a new clipboard. Gnome also allows X11
apps to push to the clipboard at any point.
Make a roundtrip to the x server to ensure that WM_STATE changes have
been propagated. xcb_flush() is not good enough, there's still a race
condition between the wm flushing its connection and the client reading
window properties.
While KWin may not have information about the formats, that doesn't mean KWin
should filter them out - EGL can still import them, so allow clients to use them
*Second in series after https://invent.kde.org/plasma/plasma-workspace-wallpapers/-/merge_requests/17*
Another patch will follow from the translations SVN, after I figure out how to work with it.
In kwin repo alone, there's another 4MB in savings with funny files like those:
```
kwin/po/ru/docs/kcontrol/windowspecific/tbird-reminder-info.png
[oxipng] Reduced by 768.94 KB (-96.42%) from 797.52 KB
```
The main benefit from doing this is that kwin is going to handle
maximizing the window by dragging it on touchscreen correctly if the
pointer focus point and touch focus point are on different screens.
The "!isMovable()" code path is needed to handle moving fullscreen windows.
Maximized windows are movable and their geometry is computed in
Window::nextInteractiveMoveGeometry().
our plasmoid only listens to signals when the interface was found.
also when switching from 2 to 1 layout we'd emit a signal that the
layouts changed but then we'd throw away our interface leaving
the client wondering what happened to us (and consequently
printing warnings because our service wasn't found)
this specifically resulted in the plasmoid not getting layout event
changes when switching from 1 to >1
BUG: 449531
The main motivation behind this change is to make the code in
Window::handleInteractiveMoveResize() more reasonable. Almost all of the
code in it will be called after startInteractiveMoveResize(), except
when one drags the decoration to initiate an interactive move operation.
This change moves that code to the places where it makes more sense to
ensure that handleInteractiveMoveResize() has no any hidden pitfalls.
Unlike X11, on Wayland, the window won't change its maximize mode until
it renders a new buffer. This creates a problem for interactive move
because if it's not careful and moves the window while it's still effectively
maximized, it will look as if the window has leaked to other screens.
This change fixes the problem by making Window::handleInteractiveMoveResize()
avoid move() if the window needs to be unmaximized.
As a bonus, it also allows to unmaximize the windows that are maximized
along only one dimension by dragging them.
Unfortunately, tiling stuff still suffers from the same issue. In order
to fix it, Window::tile() has to be part of double buffered state, like
Window::maximizeMode().
BUG: 449105
BUG: 459218
CCBUG: 482085
