Boolean traps are a code smell that makes code harder to read and it
also usually makes the api more difficult.
The force == false is used by two places:
- in Workspace::restackWindowUnderActive()
- and in X11Window::restackWindow()
Technically, the restackWindow() function doesn't need the force == false
behavior because the stackBelow() function is used in code paths where an
explicit sibling is provided.
The restackWindowUnderActive() function is trickier, it is used in the case
when kwin rejects to raise a newly mapped window, so for that purpose, I
changed the function so it picks the lowest window that belongs to the same
application as m_activeWindow.
The result of this change is that the stackBelow() is simpler and its
behavior is much more predictable, which is important when analyzing the
code that updates the stack.
There are several ways how a window can be restacked relative to another:
either by placing it below the reference window or above the reference
window.
Currently, the restack() function places the given window below the
refererence window. But it's hard to decipher from the name, one needs
to take a look at the argument names to understand what's going on.
Another reason to rename is that it could be useful to have a stackAbove()
function to make X11Window::restackWindow() implementation simpler and
more straightforward.
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.
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
While tabbox switching is usually a keyboard operation, we offer also
a mouse-friendly way to launch it via screen edges, and should allow
to switch directly on mouse click.
BUG: 481267
FIXED-IN: 6.0
This reverts commit b31baaf0cd.
It's still a good idea to show the task switcher even if there's only
one window in order to provide the user feedback about their action.
Since the task switcher is not shown when there's only one window, it
can be confusing and lead to thinking that the task switcher is broken.
It also fixes a regression which prevents alt-tabbing to the only
remaining minimized window.
BUG: 480940
CCBUG: 419408
By default the focus item in a tabbox is always the main item, so if the
main item is not a focus scope, the inner item will not get focused.
BUG: 477286
FIXED-IN: 6.0
In default shortcuts, change +Shift+Backtab to +Shift+Tab.
Functionally the behavior doesn't change.
But Shift+Tab is better since it is
- easier to understand (not everyone knows what Backtab is)
- more consistent with other shortcuts containing Shift:
we use Alt+Shift+1, instead of Alt+Shift+!
- more consistent with how user defined shortcuts with Shift and Tab are
displayed and stored
BUG: 422713
FIXED-IN: 6.0
When users simultaneously press Shift and Tab, the keys are sometimes
registered as Shift+Tab, and sometimes as Shift+Backtab.
So we need to match received Shift+Tab against shortcuts containing
Shift+Backtab, and vice versa. Previously the code only checks for
the first case. This commit adds checks for the second case.
BUG: 438991
FIXED-IN: 6.0
Closed windows are present in the stack. If user has selected
"Stacking order" sort order in task switcher KCM, we need to guard
against closed windows in the stack.
