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
This provides the grab point that controls the interactive move resize
operation. It can be used outside Window::handleInteractiveMoveResize()
to position XdgToplevelWindow when a configure event is acked.
Window::interactiveMoveOffset() stores the move offset in pixels, but it
is somewhat annoying to deal with when the window size changes, for example
when the window is unmaximized.
This change makes Window::interactiveMoveOffset() store a ratio where
the move offset can be found. This simplifies the code a bit and fixes
the cursor jumping to the topleft window corner. Although there are other
glitches.
CCBUG: 449105
Instead of not-delaying cursor updates with adaptive sync, this forces a
software cursor instead. That way, the functionality works the same on all
the vendors.
For testing potential driver fixes, the environment variable
KWIN_DRM_DONT_FORCE_AMD_SW_CURSOR=1 can be used to disable this workaround
Previously m_keysym was only updated on key press. This caused issues
when multiple keys are pressed at the same time. E.g., if the user
presses A, presses B, releases A, releases B, the actual events sent by
kwin was A pressed; B pressed; B released; B released.
Also call xkb_state_update_key after xkb_state_key_get_one_sym, as
recommended by the libxkbcommon documentation
XKB_KEY_KP_9 is 0xffb9 while XKB_KEY_KP_Equal is 0xffbd and XKB_KEY_F1
is 0xffbe. So XKB_KEY_KP_Equal, instead of XKB_KEY_KP_9, has the maximum
keysym for keypad keys.
Seat has to handle two types of drags; ones where clients are updated
through data device, and xwayland version where the drag target has
mouse events sents as pointer events. A mechanism to treat them
differently was introduced, but this former xwayland hack was not
included. We also don't need to send frame events when in datadevice
mode.
This reset of pointer state breaks electron.
