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.
...because layer-shell clients are not views and we want to be able to
use foreign-toplevel protocol on the active view even if a client such as
a panel has taken keyboard focus.
Written-by: @Consolatis
Fixes: #1336
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.
...so that svg and png icons only support the max_toggled_hover format.
There is no need to support max_hover_toggled because there are no
backward compatibility considerations as Openbox does not handle png and
svg icons.
...and treat max_hover_toggled.xbm as an alternative name supported for
compatibility reasons.
Use the following button filename schema: "BUTTON [TOGGLED] [STATE]"
with the words separted by underscore and with the following meaning:
- BUTTON can be one of 'max', 'iconify', 'close', 'menu'
- TOGGLED is either 'toggled' or nothing
- STATE is 'hover' or nothing.
This is consistent with the openbox.org wiki and it is believed that this
is how the vast majority of extant openbox themes out there are written.
But please be aware that it is actually different to vanilla Openbox which
uses: "BUTTON [STATE] [TOGGLED]" following a commit in 2014 which broke
themes and led to some distros patching Openbox:
35e92e4c2a
Arch Linux and Debian patch Openbox to keep the old syntax (the one that
this commit aligns us with).
https://gitlab.archlinux.org/archlinux/packaging/packages/openbox/-/blob/main/debian-887908.patch?ref_type=heads
Prevent carrying around the wlr_output->data pointer when
destroying an output. The set_gamma handler may be called
during the destruction of a wlr_output after our own
destroy handler has already been called. This patch resets
the wlr_output->data pointer in our destroy handler and
adds a check in the set_gamma handler to verify the output
is actually valid.
Fixes#1270
Reported-by: @Flrian
All non-modifier keys cycle forward which makes sense for
e.g. tab but is not very intuitive for arrow-up or arrow-left.
Handle those keys separately to provide a feel of navigation
by arrow keys in the cycle view OSD.
This function has grown quite large over time. Breaking out various
smaller functions makes the logic easier to follow.
No functional change intended, but there is a minor logical change:
- Due to factoring out match_keybinding(), each keypress can only
match a single keybinding now. Previously, it was theoretically
possible for a single keypress to map to multiple keysyms which could
each match a different keybinding.
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.
