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.
Tablet tools are independent of tablets but the way our code is
structured is that it assumes they are not. For example, the same tool
can move between two different tablets.
This change introduces the InputDeviceTabletTool type which abstracts
tablet tools. It allows to look up TabletToolV2Interface by just looking
at the tablet tool pointer.
It also opens up "smarter" strategies to clean up stale tool objects.
Previously, there used be issues with unregistration of tablet input
devices, which are resolved now. So, the null checks can be dropped to
make the code easier.
As of now, only libinput tablet input devices are properly registered
with the wp_tablet_v2 protocol. This is not great for testing purposes
and it limits the options how we would structure the code, e.g.
the wp_tablet_v2 implementation can't work with InputDevice even though
it would be nice to offload some things from tablet_input.cpp to it.
If we change the backend the colormap will get leak, the colormap should
be released with xcb_free_colormap before the window destoryed.
Signed-off-by: Chaojiang Luo <luochaojiang@uniontech.com>
Since the position of the contentItem depends on the position and scale
of the parent item, make sure to re-evaluate it when the parent changes.
BUG:495501
This is needed to workaround a test failure in testButtonRebind. The
current issue is that tablet input is built around libinput backend,
but tests create fake input devices to represent tablets, so things such
as TabletV2Interface or TabletPadV2Interface are not registered as
expected.
In order to address the issue, input devices need to expose tablet
specific metadata in some way that doesn't require using libinput specific
apis. This will be done later.
Once the tests are fixed, we should be able to drop tablet null checks
in tabletToolEvent() functions.
Device group user data is a libinput specific concept, and it's not
portable to other platforms/backends, which we need to support in long
term for proper testing of tablet stuff in CI, etc.
Note that tablet input still heavily pokes libinput specific things,
this is going to be addressed later.
Tablet pad and tablet tool input devices can be announced in any order.
The problem with the current code is that it is going to create a
TabletV2Interface object when a tablet pad is registered first. In addition
to that, it unsets the user data (TabletV2Interface) in libinput device
group without checking whether the tablet tool is actually removed.
Another issue is that if a tablet pad is registered first, then the
TabletV2Interface is going to have the metadata of the tablet pad input
device. Tablet pad and tablet tool devices are often represented separately.
BUG: 493027
Maintaining tablet <-> pad one-to-one mapping is not quite accurate.
A tablet can potentially have more than one pad paired with it.
The main motivation behind this change is to decouple tablet pad
registration from tablet tool registration.
The InputDevice is useful for determining the origin of the event.
TabletPadId acts like it, but it still suffers from issues where we
need to access the InputDevice.
Currently, tablet pad event data is provided using function arguments,
but this approach is not good in long term. For example, if more data
needs to be supplied, then every user needs adjustments.
This change introduces more tablet event types to make the code more
flexible in terms of extending event payload.
After 5f85280563, when clicking a window,
it will be raised on button release. While it works as expected for
dnd, for interactive move or resize, it's preferred to raise the window
as soon as it's possible.
Item::scheduleRepaint() invalidates part of an item. It doesn't
invalidate the corresponding part of the scene globally. There are a
couple of reasons why it works the way it is:
- the first, and the main one, is to keep effects like blur working
- the second is to cull out invisible repaints, i.e. repaints scheduled
by obscured items
This kind of repaints is suitable when the size or the position of the
item changes. However, it's not good in case the stacking order changes.
For example, consider two sibling items: `[A, B]`, `B` is on top of
`A`. If the `z` of item `B` is set to `-1`, the effective stacking order
will be `[B, A]`, and only repaints for item `B` will be scheduled. When
`WorkspaceScene::preparePaintSimpleScreen()` processes the next frame, it
will see that item B is occluded by item A, so it will discard item B's
repaints and the corresponding graphics buffer will _not_ be repainted
even though it should be.
In order to prevent that, we need to schedule a global repaint.
Is there a less error prone design? Yes, if we could specify the contents
of every frame declaratively, then we could diff two consecutive frames
without manual meticulous repaint tracking. The magnitude of such changes
is beyond a bugfix though.
By default, we want the primary GPU to be one that displays are connected to, and if we're
on a laptop, one that the internal display is connected to.
BUG: 494749