When labwc un-tiles views, it generally changes their size, which sends
a configure request to the client. However, because the view has been
disabled in the wlroots scene, it will not receive and process the
configure when labwc expects. Instead, the handling will be deferred
until the user unshades the view at some arbitrary time in the future,
resulting in labwc registering complains like
[../src/xdg.c:239] client did not respond to configure request in 100 ms
Furthermore, the reconfigure will still generally produce flicker (as
the view opens in its tiled size and then jumps to its natural
geometry). Because skipping the unshade might cause client problems and
doesn't eliminate the problem it sought to resolve, let's revert this.
This reverts commit 2e19bd4d5b.
Applies drag resistance unidirectionally for horizontally/vertically
maximized windows, allowing them to be dragged without being untiled
immediately. When the distance of cursor movement orthogonal to the
maximized direction exceeds <resistance><unMaximizeThreshold>.
While dragging a horizontally/vertically maximized window, edge/region
snapping is disabled to prevent unintentional snapping and overlays.
This commit also includes some refactoring to simplify the logic.
<resize><drawContents>[yes|no] configures whether to let the clients
redraw its window content content while resizing.
When <resize><drawContents> is set to no, a multi-rect is shown to
indicate the geometry of the resized window.
As wlr_xwayland caches the pixel data when not yet started
up due to the delayed lazy startup approach, we do have to
re-set the xwayland cursor image when reloading the cursor
theme. Otherwise the first X11 client connected will cause
the xwayland server to use the cached (and destroyed) pixel
data.
To reproduce:
- Compile with b_sanitize=address,undefined
- Start labwc (nothing in autostart that could create
a X11 connection, e.g. no GTK or X11 application)
- Reconfigure
- Start some X11 client
... at the same time. Omit cursor notifications from
a pointer when a tablet tool (stylus/pen) is in
proximity. We expect to get cursor notifications
from the tablet tool instead.
This gives instant feedback when changing cursor theme or size.
It only works for server side cursors or clients using the
cursor-shape protocol.
Fixes: #1619
Addresses UX degradation introduced by commit 1d3ed457.
This prevents clicks with small movement with the intention of opening
the menu from unexpectedly closing the menu or selecting a menu item.
In OpenBox, when cursor button is pressed to open menu, a subsequent
cursor button release can perform actions or close the menu.
This commit makes labwc follow that behavior.
Fixes: #1750
...where dnd does not finish properly on cursor-button-release if there
is no surface under the cursor such as on the desktop when no background
client is running.
Written-by: @tokyo4j
Fixes: #1673
This fixes that, when a CSD window is dragged into below waybar and the cursor
button is released, the cursor focus is moved from the CSD window to waybar and
a release event is sent to waybar, not original CSD window.
...and unify region overlay and snap-to-edge overlay into overlay.c.
Snap-to-edge overlay is delayed for 500ms to prevent flickering when
the view is dragged from an output to another (demo in discussion labwc#1613).
This also fixes a bug that region overlay is not shown when a modifier
key is re-pressed.
...because click on different parts of a client should not be
interpreted as a double click.
Previously only cursor-button and view were validated to be the same
between clicks. This resulted in, for example a click on the client
surface itself quickly followed by a click on the SSD titlebar being
interpreted as a double-click on the titlebar.
Fixes: #1657
This means that the logic described in 2ff026b will be used when a
layer-surface is pressed on with a cursor button. For example, a surface
with on-demand keyboard interactivity will not steal focus from a client
with exclusive keyboard interactivity.
...to give keyboard focus to layer-shell clients if exclusive or on-demand
interactivity is set, so that menu popups can be navigated with the
keyboard. This still only works if the client is in top (or overlay)
layers. Support for bottom and background to be done as a separate patch
set.
Revert 06b19f0 to process layer-shell subsurfaces in
`cursor_button_press()`, but only when their parent layer-shell surface
has keyboard interactivity.
Fix bug in `get_cursor_context()` which resulted in layer-surfaces not
being detected correctly.
Background:
Commit 06b19f0 (issue #1131) disabled processing of layer-shell
subsurfaces in cursor_button_press() because when pressing a task in
Waybar (Gtk panel using layer-shell subsurfaces) the foreign-toplevel
minimize-raise action did not work correctly as the action logic relied on
the recipient window being activated and by clicking on the panel, the
panel itself was both surface-focusd and activated (and thus the window
de-activated).
The un-intended consequence was that by not responding to layer-subsurface
cursor buttons presses, layer-shell clients (such as panels) were not
given keyboard focus if they indeed wanted it by setting exclusive or
on-demand keyboard interactivity.
The good news is that that following @jlindgren90's refactoring (various)
the only place where we call `view_set_actived()` is in
`focus_change_notify()` in `seat.c` and we now only do it for views
(bb8f0bc).
Another side-effect (positive) of 06b19f0 was that a Waybar dnd bug was
fixed (pointer-serial-number validation failure).
Have tested with sfwbar, waybar and tint (test-panel) the following
results:
- Minimize-raise works even when on-demand keyboard interactivity is set
- Keyboard interactivity is given popup-menus (sfwbar and tint) when the
panels are in the top layer (support for bottom will be as a separate
patch set)
- Waybar dnd still works (even when hard-coding keyboard-interactivity)
References:
- bb8f0bc960
- 40ce95a68c/src/seat.c (L481-L483)
- 40ce95a68c/src/dnd.c (L24)
- https://github.com/johanmalm/tintFixes: #1572
This builds on the work of @Consolatis in #1018.
Co-authored-by: Consolatis <35009135+Consolatis@users.noreply.github.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
...and call actions after closing menus so that virtual keyboard input
caused by actions are sent to the surface with keyboard-focus rather
than being consumed by the open menu.
Fixes: #1366
When assertions are disabled, providing an unexpected input to
cursor_get_from_edge will cause the non-void function to terminate
without a return value. This may be effectively unreachable in practice.
However, returning a default cursor as a fall-through case will both
silence a compiler warning and prevent catastrophy should the function
ever be called with a permitted value.
We already allow some xwayland-unmanaged surfaces to take focus on map,
if indicated by wlr_xwayland_or_surface_wants_focus(). But once these
surfaces lose focus, they never regain it again.
Add desktop_focus_view_or_surface() and call it in the appropriate
places to allow these views to regain focus in the usual ways (e.g.
clicking on them or focus-follows-mouse).