...as it needs to be set before honouring xwayland_surface->fullscreen
because that calls desktop_update_top_layer_visiblity() which relies on
view->surface being set in view_is_focusable() since 13d0b14.
Fix bug introduced by PR #1237 which fails to hide the xfce4-panel (or
any other layer-shell client in the top layer) whilst gaming in
fullscreen. The bug can be observed with the following games:
- Alan Wake 2 (wine)
- Starfield (steam+proton)
- Cyberpunk (steam+proton)
- Quake 1 Remaster (steam-native)
Fixes: #661 (the last bit of it)
Reported-by: @ScarecrowDM
Helped-by: @Consolatis
Reproduce issue by:
1. Run an XWayland client
2. ToggleDecorations twice to hide deco
3. Minimize/unminimize from panel
4. Observe that deco is back
Reported-by: @Consolatis
Until we expose the workspaces to xwayland we need a way to
ensure that xwayland views on the current workspace are always
stacked above xwayland views on other workspaces.
If we fail to do so, issues arise in scenarios where we change
the mouse focus but do not change the (xwayland) stacking order.
Reproducer:
- If followMouse is enabled, raiseOnFocus must be disabled
- Open at least two xwayland windows which allow scrolling
(some X11 terminal with 'man man' for example)
- Switch to another workspace, open another xwayland window
which allows scrolling and maximize it
- Switch back to the previous workspace with the two windows
- Move the mouse to the xwayland window that does *not* have
focus
- Start scrolling
- All scroll events should end up on the maximized window on
the other workspace
This patch fixes the issue by simply raising all windows from
the current workspace again in their original stacking order
when switching workspaces.
Reported-by: Domo via IRC (thanks!)
The bug can be reproduced by using the following keybinds and then taking
the steps below with an XWayland client, for example xterm:
<keybind key="C-S-h">
<action name="GoToDesktop" to="left" wrap="yes"/>
</keybind>
<keybind key="C-S-l">
<action name="GoToDesktop" to="right" wrap="yes"/>
</keybind>
1. Press C-S-h
2. Press C-S-l
3. Observe llllllll.... in xterm
Store the key-state in `handle_keybind()` before any call to
`action_run()` as this may lead to `seat_focus()` which passes
'pressed-sent' keys to the new surface.
This partially reverts 7571c4b, which as a standalone commit was fine, but
when 'pressed_mods' were then included in 'bound' in 98bf316,
`key_state_store_pressed_keys_as_bound()` was again required in
`handle_keybind()` to ensure modifers are not passed as non-modifiers in
`wlr_seat_keyboard_notify_enter()` in `seat_focus()`
This prevents applications from seeing and handling the release event
for a modifier key that was part of a keybinding (e.g. Firefox displays
its menu bar for a lone Alt press + release).
These exceptions were added to prevent certain keys (modifiers and
synthetic layout switch key-events) from disabling keybindings (due to
the "nr_pressed_keys > 1" check). That check no longer exists, so the
exceptions should no longer be necessary.
Partially reverts e77330bc3f and 3e2baa3f05.
This restriction should be unnecessary now (see the previous commit for
details) and caused issues with keybindings not working on some systems
where irregular keypress events are received (e.g. XF86XK_WakeUp)
without an accompanying release event.
Kept separate from the previous commit for the sake of potential future
bisects.
Partially reverts e77330bc3f.
Before commit e77330bc3f, there were issues with keys becoming "stuck"
if other keys were pressed at the time a keybinding was matched, because
those other keys were included in the "bound" set and the release events
were incorrectly eaten by labwc.
Commit e77330bc3f solved that issue with the "big hammer" approach of
preventing keybindings from working at all if other keys were pressed:
if (key_state_nr_pressed_keys() > 1) {
return false;
}
This is an alternate approach to solving the original problem, by (1)
not including those other keys in the "bound" set and (2) making sure we
always forward release events for un-bound keys to clients (even if a
menu or OSD is displayed).
Details:
- Since we only ever want to store the single matched keycode as bound,
key_state_store_pressed_keys_as_bound() doesn't really make sense in
the plural, so rename it to key_state_store_pressed_key_as_bound() and
pass in the keycode.
- The calls to key_state_store_pressed_keys_as_bound() within
handle_keybinding() appear to be redundant since it is also called
from the parent function (handle_compositor_keybindings()). So remove
these calls.
- Finally, rework the logic for handling key-release events so that we
always forward release events for keys not in the "bound" set.
This PR does not remove the "key_state_nr_pressed_keys() > 1" check, and
because of that should not result in any functional change. It should
however make it possible to relax or remove that check in future.
Remove wlr_seat_set_keyboard() from `keyboard_modifiers_notify()`
but leave it in `keyboard_key_notify()`
Fixes regression introduced in 984aeb0
Reported-by: @jlindgren90
Fixes: #1238
...to address regression introduced by 57075ce and enables panel/desktop
clients which rely on window rules to remain in the same position when
the usable-area changes (normally because an exclusive layer-shell
clients is started/finished).
Also disallows interactive move/resize, for example by alt +
mouse-press.
Fixes: #1235
1. Prevent window snapping triggered by mouse from moving the window
into the adjacent output.
2. Make the coordinates used to check whether window snapping is
triggered relative to the output the cursor is at, not the output the
view is belonging to. This allows users to grab a tiled window and move
it into another output or tile it again in another output in a single
drag.
Qt applications occasionally fail to call set_window_geometry after a
configure request, but do correctly update the actual surface extent.
This results in a mismatch between the window decorations (which follow
the logical geometry) and the visual size of the client area. As a
workaround, try to detect this case and ignore the out-of-date window
geometry.
Fixes: #1194
The top_left_edge_boundary_check() function in xwayland.c ensures that
views trying to position themselves at 0,0 don't end up with a titlebar
offscreen. However, it doesn't take into account the usable area and
thus these views can still end up overlapping a top panel.
Also, there is no good reason for top_left_edge_boundary_check() to be
xwayland-specific. This logic should really be part of
view_adjust_for_layout_change().
To fix all this, add a new view_adjust_floating_geometry() function,
which replaces the existing similar (and duplicated) logic in
view_apply_natural_geometry() and view_adjust_for_layout_change().
view_adjust_for_layout_change() is already being called from xwayland's
set_initial_position(), so top_left_edge_boundary_check() is now
redundant and can just be deleted.
Lightly tested with waybar and feh --geometry 640x480+0+0. The feh
window is now correctly positioned below waybar, even if started before
waybar (in that case, the feh window is moved when waybar starts).
Fixes#1076
It can be enabled with a config like
~/.config/labwc/rc.xml:
<keyboard layoutScope="window">
~/.config/labwc/environment:
XKB_DEFAULT_LAYOUT=de,us
XKB_DEFAULT_OPTIONS=grp:alt_shift_toggle,grp_led:scroll
With a configuration like this each window should now remember
the active keyboard layout when switching between windows.
By default, the keyboard layout keeps being a global state.
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).
The type enum view_edge used to be defined in a .c file, so a
structure member 'tiled' in struct view had to be defined to
use another type.
Later (2023-08-02, commit 1ee8715) the definition of enum view_edge
was moved to view.h, so now 'tiled' can be defined to use that type.
This is a useful (if lesser-known) feature of at least a few popular X11
window managers, for example Openbox and XFWM4. Typically right-click on
the maximize button toggles horizontal maximize, while middle-click
toggles vertical maximize.
Support in labwc uses the same configuration syntax as Openbox, where the
Maximize/ToggleMaximize actions have an optional "direction" argument:
horizontal, vertical, or both (default). The default mouse bindings match
the XFWM4 defaults (not sure what Openbox has by default).
Most of the external protocols still assume "maximized" is a Boolean,
which is no longer true internally. For the sake of the outside world,
a view is only "maximized" if maximized in both directions.
Internally, I've taken the following approach:
- SSD code decorates the view as "maximized" (i.e. hiding borders) only
if maximized in both directions.
- Layout code (interactive move/resize, tiling, etc.) generally treats
the view as "maximized" (with the restrictions that entails) if
maximized in either direction. For example, moving a vertically-
maximized view first restores the natural geometry (this differs from
Openbox, which instead allows the view to move only horizontally.)
v2: use enum view_axis for view->maximized
v3:
- update docs
- allow resizing if partly maximized
- add TODOs & corrections noted by Consolatis
Currently xwayland views are restacked on top of the XWayland server
stacking order when activated (i.e. focused). This is wrong because
focus/raise are independent concepts (though often occurring together).
The stacking order should be updated when the view is raised/lowered,
not when the view is focused.
Work is in progress elsewhere (draft PR) that will result in views more
often being raised without being focused. Without this fix, those views
don't get restacked properly, resulting in clicks "passing through" to
views underneath.
The logic was the same for xdg-shell and xwayland views, so move it from
the view->impl layer out to the view_move_to_front/back() functions.
view->impl->move_to_front/back() still exist for now, in case we want to
add xdg/xwayland-specific logic in future, but they now move only one
view and not sub-views.
This makes the code a bit more readable IMHO (and forces us to be
consistent with event handler function names).
Adjust scripts/checkpatch.pl to not complain.
