Whenever the output layout changes, each view's original geometry will
be captured as last_layout_geometry (if it has not already been captured
by a previous layout change), which will remain valid unless the user
modifies the view's geometry (i.e., by tiling, maximizing, moving,
resizing or full-screening). On subsequent output layout changes, views
with valid last_layout_geometry will be back to their original position
if possible, or else to the closest possible output.
The view_adjust_floating_geometry function is called when un-maximizing
a window or changing the output layout to ensure that views are well
placed. Rather than always centering these views should they fall
offscren, use the automatic placement strategy if so configured.
It is nice to have finer granularity for device types to allow for
configurations such as using `naturalScroll` on touchpads, but not on
regular pointer devices such as mice.
Support showing full application
identifier or the trimmed variant in window switcher OSD.
Regression notice: For anyone using ‘identifier’ in window-switcher field configuration, change it to ‘trimmed_identifier’.
Some themes don't have hover variants for button pixmaps.
It looks better visually to use the non-hover variants as fallbacks
rather than the built-in 6x6 pixmaps.
Account for space taken up by XWayland panels (as indicated by the
_NET_WM_STRUT_PARTIAL property) in the usable_area calculation.
This makes it possible to use labwc in a "transitional" setup, where it
replaces the X11 window manager and compositor, but most other parts of
a existing X11 desktop environment can still be used via XWayland.
(Some remaining drawbacks of such a setup would be the lack of desktop
icons, and native Wayland clients not showing up in X11-based taskbars.)
XWayland clients use the _NET_WORKAREA root window property to determine
how much of the screen is not covered by panels/docks. The property is
used for example by Qt to determine areas of the screen that popup menus
should not overlap (see QScreen::availableVirtualGeometry).
Depends on wlroots MR:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4406
v2: prevent calling wlr_xwayland_set_workareas() too early
v3: fix segfault at exit (server->xwayland == NULL)
Chases: 756ecf8ee9f1e75bc7b8297dc84f97c7d699174b
backend/wayland: use request_state when toplevel is resized
Chases: 3ef68a484243555b020200c6f95246d994932c3f
backend/x11: use request_state when window is resized
Ref: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2693
We now delay requested resolution changes by the backend until
the next frame event which causes us to render the new content
on the already enlarged buffer. Before this change, an empty
(black) buffer would have been shown instead before the next
frame event caused a new render of the actual contents.
Keep commiting the new state and then scheduling a frame event
would not help as due to the commit call it would still show an
empty buffer in the meantime.
Just modifying wlr_output->pending wouldn't work either because
wlr_scene_output_commit() *completely* ignores it (and it will
be removed in future wlroots commits). For this reason we move
to wlr_scene_output_build_state() directly because it allows us
to supply the current wlr_output->pending state and thus apply
any resolution change in lockstep with new rendering. Result:
No more flickering in the wayland backend and resizing is again
smooth as butter.
This prevents constant flicker while resizing
when running nested via the wayland backend.
For the X11 backend (can be tested via `WLR_BACKENDS=x11 labwc`),
it is still rather janky but at least doesn't cause endless self-
resizing anymore.
Need to handle new unified mapping, where mapping is attached to the
wlr_surface objects instead of their parents. Also, most of them require
a new associate event for xsurface objects, their surface member will be
NULL before this event is received.
Refactored by jlindgren:
- add struct mappable
- unify map/unmap logic
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!)
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).
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.
