If the screen is locked, but the lockscreen isn't ready for painting,
pickFocus() returns the active window. This somehow leads to the
meta key getting "stuck" if you lock the screen with Meta+L.
BUG: 495325
QInputEvent doesn't behave as we expected, if two input events are created
(it's pretty common when kwin needs to forward an event to a decoration,
etc), the last event can change the values in the first event even though
they are completely unrelated, which later breaks input processing in kwin.
See https://bugreports.qt.io/browse/QTBUG-121987
It just wrongly triggers modesets that will then (at least try to) ignore the
leased-away resources anyways, and regress performance on the other displays.
BUG: 495400
This new return value is mainly intended for usage trough scripting.
In scripting there was no safe way to know which were the two "new"
tiles after splitting, because two things can happen: either
two new child tiles are created or if the layout direction agrees
with the current layout, a new sibling is created, so we can't
rely on tile.tiles.
This makes it return an Array containing the result of the split,
making scripts much cleaner and with less heuristics.
This change introduces a check for the ID_INPUT_TOUCHPAD property to
reliably identify touchpad devices. By doing so, we ensure that the
logic specific to touchpads is applied only to the relevant devices,
improving the overall robustness and accuracy of input handling. this
enhancement addresses issues where non-touchpad input devices were
incorrectly processed as touchpads, leading to unintended behavior.
Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>
If another window accepts the touch up, that can seriously mess up the touch state and
cause for example the overview effect to misbehave when we have 2 screens.
Before, it could break in the following scenario:
- drm backend emits aboutToTurnOff
- workspace creates the dpms filter
- workspace gets some event that triggers it to update outputs
- maybeDestroyDpmsFilter sees that the output is on and deletes the dpms filter
- the drm backend actually turns the screen off
In that case, the dpms input event filter is gone and the output off. Unless the dpms mode
gets changed again by some other process, the output would now stay off forever.
The wp-tablet-v2 protocol implementation no longer uses this property,
and, in general, InputDevice::name() is more preferred as it's more
widely supported.
Since the ensureTabletTool() function is called before forwarding the
event to the event filters, the ForwardInputFilter doesn't need to
create a TabletToolV2Interface object anymore.
Tablet implementation is very input device oriented. If the tablet
protocol implementation works with InputDevice, we could offload some
tablet matching logic to the wayland protocol implementation as well
as making TabletInterface <-> InputDevice lookup more robust in case
sys names are unavailable.
We need a way of disabling interactive window moving in Plasma Mobile
(see: https://invent.kde.org/plasma/plasma-mobile/-/issues/340).
This adds a property on the window that lets us toggle interactive
window moving from a config setting.
The last two commits fix tabbox behaviour when the active client is
missing from the client list (e.g. when the tabbox only shows windows on
other screens, desktops, or activities). Since both commits depend on
each other, only add the test now.
When invoking the tabbox we initially advance the selection by one,
assuming the first item in the client list is the active window which
we'd like to skip. However, since we allow the user to apply a filter to
the clients displayed in the list, we might end up with the active
window missing from the current client list and skipping over an
unrelated client. When using focus chain switching this means we skip
over the last focused window, making quick switching between two windows
impossible.
Instead of advancing the selection unconditionally, make sure not to
advance if the client list does not contain the active window and we are
in the initial invocation of the tabbox in navigatingThroughWindows().
When resetting the tabbox before making it visible, we want to set the
index to the active window as our starting point. It might happen that
the active window is not part of the selection model, for example when
the tabbox is showing only windows on other desktops or activities. If
this happens the index is invalid, so we want to take care to set the
index to the first item instead.
Currently we handle this by first attempting to set the index to the
active window with setCurrentClient() and then afterwards checking
whether currentIndex() is valid. However, setCurrentIndex() only changes
the index if it is valid, so the index is never changed and remains at
its previous valid position. This makes the following check with
currentIndex() irrelevant and the index is never reset to the first
item.
What this means in practice is that a tabbox whose client list does not
contain the active window initially has whichever client selected that
corresponds to the index set in a previous invocation of tabbox.
To fix this, look up the index of the active window first and only set
the current index to it if it is valid. Otherwise set the current index
to the first item.
When dropping a thumbnail on another desktop, don't animate the
position, otherwise we see the window oddly flying off the screen
to go on its new position on the different desktop
BUG:495444
The given preferred output can be already removed from the Workspace
when the layer shell window is created. In which case, we should close
the layer shell window.
This fixes a porting typo. Previously, the modal was therefore
added twice, once for itself and once for its parent but we actually
do *not* want a window with a modal child at all.
Currently, input devices depend on InputRedirection for the event enums.
Move them to the InputDevice to prevent input backends depending on higher
level abstraction layers.