If a focussed window is to a new virtual desktop we need to update focus. It
does not make sense for focus to remain on a now-invisible window. This patch
re-uses the same path as when virtual desktop is changed.
BUG: 481574
Currently, the quicktile hotkeys are "absolute" in the sense that
pressing "Meta+Left" always tile the window to the left half of the
screen, regardless of its current quicktile position.
https://invent.kde.org/plasma/kwin/-/merge_requests/50@ngraham partially
changed this behavior so that if you press "Meta+Left" followed by
"Meta+Up" in one second, the window will be tiled to the top-left.
This commit generalizes the above behavior so it works any time,
without the one-second limit. This is inspired by the COSMIC desktop's
design.
demo:
The new behavior is as follows:
```
+--------------+-------------+--------------+-----------+--------------+
| current pos | key:left | right | up | down |
+--------------+-------------+--------------+-----------+--------------+
| left | no change | restore | top-left | bottom-left |
| right | restore | no change | top-right | bottom-right |
| up | top-left | top-right | no change | restore |
| down | bottom-left | bottom-right | restore | no change |
| top-left | no change | top | no change | left |
| top-right | top | no change | no change | right |
| bottom-left | no change | bottom | left | no change |
| bottom-right | bottom | no change | right | no change |
| normal | left | right | top | bottom |
| maximized | left | right | top | bottom |
+--------------+-------------+--------------+-----------+--------------
```
Diagonal hotkeys like "quicktile to top-left" are processed as left then up.
Pros:
* I find this model ("moving / spanning window to this direction") more natural.
* Currently when a window is already tiled to left and the user presses "meta+left" again, it moves to the screen on the left side, and tiles to right. This also matches the "moving window" mental model than an absolute one.
* Fewer key presses to move a window to adjacent positions, e.g. from "left" to "top-left".
Cons:
* More key presses to move a window to the opposite position, e.g. it now requires two "meta+right" to move a window from "left" to "right".
Maximize mode cannot be expressed using quick tiling infrastructure
because its semantics are very distinct from the quick tile modes.
For example, maximized vertically or horizontally require processing
interactive moves in a way that makes no sense for tiling.
There was no synchronization between the config being changed and the test checking for the
result, so it sometimes did the action that was configured by the previous test. To fix that,
this commit unloads and re-loads the plugin, which forces it to reload the configuration
While on pointers and keyboards the focus patterns follows rather
naturally, on touch screens it doesn't so much.
This change adapts our touch infrastructure to allow for multiple
surfaces to be issued touch events without forcing all interactions into
the same one.
Signed-off-by: Victoria Fischer <victoria.fischer@mercedes-benz.com>
Workspace::cascadeOffset() can be called by placement code before the
frame geometry has a valid position. That is wrong. In order to avoid
that, use the placement area that we are given.
When the user closes the active window, with separate screen focus disabled, a
window on the other screen might get activated, which also switches the active
screen to the other one. As this is quite unintuitive, and in my testing having
separate screen focus enabled didn't have any other unintuitive side effects,
this commit enables separate screen focus by default
...by removing the keyboard flag, moving keyboard shortcut handling into a separate
method and making the position to tile the window at explicit
This also means KWin doesn't do as many intermediary changes to window geometry on output
hotplugs, which may work around some clients not always reacting to no-op changes.
CCBUG: 479694
Right now it's just a helper to mark items as being affected by some effect,
to prevent direct scanout of the relevant item without needing to block direct
scanout for the whole screen
Clients can have valid reasons to change the selection when the
same user action that also caused the selection request
to lose keyboard focus. This is notbaly the case for menus
created from a Plasma panel which itself will not take focus
but when clicking on action it only triggers after the menu
is closed.
This also matches what weston and sway do.
BUG:490803
We optionally send some keys to xwayland through the filter when no x11
client has focus. This allows shortcut handling in X11 apps to work.
When kwin is grabbing keys we don't necessarily want X11 to sniff these
keys as things can get out of sync. A key place is the tabbox. The X11
client sill has focus, but xwayland is not active. This means we pass
tab keys to X which then go to application incorrectly.
Part of this patch changes the tabbox filter to not intercept the alt
key release event. This ensures xwayland's concept of pressed modifiers
stays in sync.
BUG: 484992
In some IM backends pre-edit text should be submitted on user interaction, in some it should be discarded.
In TextInputV1 and V2 this was a flag sent to the client along with
the commit string ahead of time.
TextInputV3 does not have a flag for this, so we handle it compositor side.
We flush the text to be committed :
- when we change keyboard focus, before the current client gets wl_keyboard.leave
- when a mouse is pressed in the relevant surface
- when a key is pressed and the InputMethod doesn't have a grab
- when the InputMethod forwards a key to the client
(which includes the InputMethod passing on grabbed keys)
When the tabbox grabs input, the key events won't be sent to the client.
It's not good for a couple of reasons: first, it can fool the client into
repeating a previously pressed key; and the server side and the client
side can be out of sync after the task switcher is dismissed.
In order to handle that properly, this change makes the tabbox reset the
keyboard focus when it's shown or hidden. When the task switcher is
dismissed, an enter event will be sent with the current state of the pressed
keys.
Ideally, the same needs to be done with the pointer focus but it's
challenging to achieve with the current input pipeline design. An input
grab abstraction is needed to handle pointer focus when the task switcher
is active.
This is needed to better support emitting mouse button events when
pressing tablet buttons. It's common in many art programs that an action
is tied to a mouse button + a modifier, such as panning the canvas. So
being able to send keyboard modifiers in tandem with mouse buttons is
very useful when rebinding.
Tests are added for this new feature.
CCBUG: 469232
KeyboardInterface is a multiplexer, it has a global state to kwin
that forwards events the single focussed window.
XWayland also forwards events to clients, but uses the keyboard interface.
It has some overloads that take a specific client, this was used for key events
but not modifiers.
The end result was not only that XWayland could miss a modifier update, but
also that wayland clients would get modifier updates out of order.
Key events must come first.
BUG: 490270
If an output is deleted, the Workspace::desktopResized() is going to
re-assign windows to the new outputs. It is done so so the workspace
re-arrangement procedure is deterministic and has concrete order.
However, with the current Window lifecycle management, it's possible
to encounter the follwing case:
- xdg_toplevel gets created on output A
- xdg_toplevel initial state is committed
- output A is removed
- a wl_buffer is attached to the xdg_toplevel, which results in a
geometry change and an output change
- Window::setMoveResizeOutput() is called, but the previous output
is a dangling pointer
CCBUG: 489632
Since the tablet cursor and the mouse cursor is tracked separately,
rebinding a tablet button to a mouse click is sort of wonky. For
example, if you assign it to Right Click and attempt to open a context
menu it will appear to open in the wrong place.
So before we send the mouse button event, set the mouse position to
the tablet cursor position. A test is added to ensure this functionality
works as intended and doesn't regress.
This is to not destroy the tablet state for the next test (which is
added in the next commit.) We could also explicitly do a tablet tool
up/down dance here, but all we need is the tablet tool to be in
proximity for the tablet button event to fire.
This adds autotests for binding to tablet pad and tool buttons, which
was previously untested. Of note is that we don't explicitly test mouse
buttons, which is already tested in the other functions.
NETWinInfo queries the window state and setState() will do nothing if the
proposed new state matches the cached server side state.
On the other hand, given how the test is structured, there can be pending
fullscreen changes on the kwin side that are yet to be sent to the X server
when the NETWinInfo object is created.
This change fixes that race condition by adding an explicit Xcb::sync().
The effect only modifies the opacity of individual windows that
WorkspaceScene::scanoutCandidate will reject anyways, so there's no reason
for it to block direct scanout.
Once a more proper solution for blocking direct scanout on individual items
is in place, this can be removed again
BUG: 487780
pipewire 1.2 has a known regression where the client's process callback
will not be triggered if the producer has sent only one buffer.
The issue has already been fixed upstream
525360d70a
Until our CI picks up that change, temporarily disable the test to unblock
merging patches.
We map AltGr to Qt::GroupSwitchModifier, but then ignore it
Instead map it to Mod5, which for some reason xkbcommon doesn't expose a define for
Also, since the Qt modifiers enum doesn't map nicely to XKB modifiers introduce our own enum to avoid confusion
CCBUG: 444335
Xaver Hugl
Jarek Janik
Vlad Zahorodnii
David Edmundson
Jin Liu
Aleix Pol Gonzalez
David Redondo
Yifan Zhu
Joshua Goins
Nicolas Fella