'restrict' is harmful as it encourages the compiler to make dangerous
assumptions while increasing cognitive load on the human programmer.
The extra 1% (or whatever) of performance here is not worth the cost.
Wlroots now destroys the wlr_output when granting a lease.
So we can't iterate through the outputs in the request after
granting the lease. This is also not necessary anymore because
they are already destroyed and thus removed from the layout.
Alternative to 7bf08af which was reverted in the previous commit.
7bf08af fixed the problem that layer-shell clients are terminated when
it's unmapped, by sending configure events in node-destroy handler
rather than in unmap handler. But it caused a UAF bug when an output
with layer-shell clients is destroyed.
So this patch fixes the original issue by simply skipping the surface in
arrange_one_layer() if it's being unmapped.
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.
