The workarounds added in #2498 and #2437 fixed stuck key/modifier bug
caused by wlroots commit e218990. But now that the commit was reverted in
0.19, the workarounds are no longer needed.
Removing the workarounds also fixes a minor regression with Fcitx5+Firefox
that pressing Ctrl+Enter in an input box causes stuck modifier.
...because Alt- keybinds should be for clients to use and the A-<arrow>
default combination is a frequent user complaint because it prevents some
common usage patterns like alt-left/right in web browers.
Only Vertical and SplitVertical gradients are supported,
and only for window.*.title.bg.
Not supported at this time:
- horizontal or diagonal gradients
- gradients for window.*.label.bg, buttons, or menus
- any type of border (raised, sunken, etc.)
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.
...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
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.
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.
Offer focus by sending WM_TAKE_FOCUS to a client window supporting it.
The client may accept or ignore the offer. If it accepts, the surface will
emit a focus_in signal notifying the compositor that it has received focus.
The compositor should then call wlr_xwayland_surface_activate(surface, true).
This is a more compatible method of giving focus to windows using the
Globally Active input model (see wlr_xwayland_icccm_input_model()) than
calling wlr_xwayland_surface_activate() unconditionally, since there is no
reliable way to know in advance whether these windows want to be focused.
v2: add caution not to use view_offer_focus() directly
v3: remove obsolete comment
Ref: 1133bc15ceb2c2bcb6df692acda6bfa39a292ab5
("Transparently restack xwayland surfaces")
In addition, MR 4772 makes sure the hidden windows are stacked at the
bottom, just like what we did with XWAYLAND_VIEW_HIDDEN.
This allows users to make the icon in window switcher bigger (or smaller)
than the font size, which enables more Openbox-like appearance.
Example configuration:
osd.window-switcher.item.icon.size: 50
This commit also makes the icon smaller than the font size if the width
allocated with <windowSwitcher><fields><field width=""> is smaller than
that.
Before this commit, when a normal window is raised, xwayland thought it's
above always-on-top (AOT) windows even though it's actually below AOT
windows in the scene. This means mouse scroll events may be unexpectedly
sent to normal windows below AOT windows even when the cursor is hovering
over a AOT window.
So this commit fixes it by notifying the correct stacking order (where AOT
windows are placed above normal windows) to xwayland every time the
stacking order is updated.
Other benefits of this commit are:
- It makes the code more readable and predictable by aggregating logic
about stacking order management in xwayland (e.g. shaded windows or
windows in other workspaces should be notified to xwayland as being
placed at the bottom).
- As server->last_raised_view is removed in the previous commit, we were
notifying the stacking order to xwayland every time a window with dialog
windows is clicked (not when clicking a topmost window without dialogs,
due to some optimization in wlroots). This commit fixes this by caching
the window stacking order in xwayland_view->stacking_order and notifying
it to xwayland only when it's updated.
We were skipping in view_move_to_front() if the raised view is already
cached as server->last_raised_view. But this was prone to bugs that
windows cannot be raised even though they are actually not placed at the
top in the scene.
This happened when a window is mapped but view_move_to_front() is not
called in view_impl_map() for some reason. Example cases were:
- a window is minimized before being mapped (#2627)
- a window is mapped while window switcher is active (#2629)
Also, this problem was the root cause of #1640 and #2582, though they are
already fixed.
Therefore, this commit removes server->last_raised_view. In order to
eliminate unnecessary communications between labwc and xwayland (ref:
db591d1), I'll introduce another caching mechanism in the next commit.
