Having a hover effect visible without interaction looks out of
place when there is no cursor (the cursor becomes hidden for/after
touch interaction until next mouse or tablet interaction). Just
clear the hover effect after touch-up to prevent this.
Note that SSD hover effects are still shown during touch-move and
touch-down.
Only use the touch protocol when no labwc menu is open.
This ensure that labwc menus will be closed on first touch
down/up since cursor emulation takes care of closing a
menu.
This prevents that a labwc menu stay open during touch
interactions in native touch mode.
It doesn't matter much since those are about the combination
of tablet and tablet tool. That said, this feels slightly more
natural.
As a consequence we always create a tablet tool and decide
indirectly via `tablet_get_coords()` and the returning surface
if mouse emulation should be used or not. Now we can also
add a `motion_mode` to the tablet tool which is slightly cleaner.
- Send xdg_toplevel.wm_capabilities
- Send xdg_toplevel.configure_bounds so that clients can map a window that
fits within the usable area, without relying on
view_constrain_size_to_that_of_usable_area() which is called after map.
- (The new "suspended" state should be handled by wlr_scene in the future)
...to enable/disable primary selection clipboard support. This only works
on launch.
The reason it is useful to be able to disable this is that some clients
(like browsers) support middle-button-click to start scrolling up/down.
With some clients can be disabled via
gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false
...but for others (like chromium and electron based programs) a compositor
setting is required.
Fixes: #2815
Omit cursor notifications from a pointer when a tablet
tool (stylus/pen) is in proximity. This is equivalent
to `handle_request_set_cursor()` and prevents a resize
cursor for out-of-surface scrolling with a tablet tool in
recent GTK4 (which uses the cursor shape protocol).
Due to the asynchronous nature of view_offer_focus(), there was a race
condition that could result in no view remaining active when multiple
views were unmapped at once. Check for this and prevent it.
CLion's main window uses the Globally Active input model, and since
8fb2ecefcb it is given focus asynchronously via view_offer_focus().
However, we need to return seat focus immediately after an unmanaged
surface (e.g. popup) is unmapped, or focus is lost completely.
In 9e3785f8cd, a heuristic was added to assume that NORMAL and DIALOG
window types were always focusable. (This was before we had the "offer
focus" mechanism in place.)
However, we should still call wlr_xwayland_surface_offer_focus() for
these views, in case they actually don't want focus. (This is uncommon
but has recently been seen with WeChat popups, which have both NORMAL
and UTILITY type.)
To make this possible, refine view_wants_focus() to return either
LIKELY or UNLIKELY for Globally Active input windows. This decouples
the question of "should we try to focus this view" from the actual
mechanism used to do so.
This fixes the gap between menu items and the menu border in an output
with a fractional scale due to the semantic gap between cairo and
wlroots's position-independent scene renderer.
Using mouse emulation for a tablet tool mouse is just a practical
decision to let such a tool work more smootly, e.g. it avoids weird
menu issues in GTK applications. Since such a tool doesn't have
pen specifix axis like pressure or distance, no functionality is lost.
A solution fully in line with the protocol, which would pass the tool
mouse buttons to the client, would leave us with e.g. non-working
buttons in current GTK4 since they don't handle the buttons
reported from the tool mouse.
May be this changes in future. But for now, let's just be practical.
This prevents a crash observed by the scaled-icon-buffer listening
to the `view->events.set_icons` signal before it is initialized.
For this to happen, the application needs to use the kde decoration
protocol and set it on the xdg_surface before creating the xdg_toplevel.
Fixes: #2798
This patch fixes the issue that window icons become the fallback
one after Reconfigure, by setting scaled_icon_buffer->view_app_id (and
other properties) in scaled_icon_buffer_set_view().
The reason why the window icons were displayed before Reconfigure is that
applications usually enable decorations and then set app_id which fires
handle_view_set_icon().
This patch also changes the semantics of scaled_icon_buffer: rather than
calling scaled_icon_buffer_set_app_id() every time an app_id is set, we
can now call scaled_icon_buffer_set_view() just once so that multiple
scaled_icon_buffers bound to a window are automatically updated when an
app_id is set or new icon is set via xdg-toplevel-icon-v1.
