Move the desktop_arrange_all_views() call outside layers_arrange() into
a new function, output_update_usable_area(). The new function currently
does exactly what layers_arrange() used to, but will be expanded in a
later commit.
Add output_update_all_usable_areas(), which is the same as calling
output_update_usable_area() for each output, but only calls
desktop_arrange_all_views() once.
Rebased and slightly modified by @Consolatis
...and thus simplify the usage of wlr_scene_node_at(). Specifically:
- desktop.c: in get_cursor_context() use node-description for
layer-surfaces and layer-popups. This lays the foundations for a
pointer-enter-event being sent when a new layer-surfaces appears under
the pointer (even if the pointer doesn not move).
- layers.c:
* Iterate over `struct wlr_scene_tree *layer_tree[]` rather than
`struct wl_list layers[]` when arranging layers to avoid surfaces
being out of sync with nodes
* Set signal handlers after scene node creation to avoid configure
race conditions
* Handle scene-node destroy event rather than event of
`struct wlr_layer_surface_v1`
* Arrange layers on map and unmap
* Handle client request for layer-change
Fixes issue #667
Previously, if rc.xml defined only non-default libinput categories,
no default category was created. This meant that configure_libinput()
might totally skip configuring some devices even with default
settings, like tap-to-click.
Fix this by making sure that a default category is always created.
these should only be set on commit. doing so before then confuses
code that expects these fields to be in sync with the scene tree,
such as `handle_commit`.
these were only being set so that `view_center` could read them to
compute a centered position, so instead we can simply forward the
values directly to `view_compute_centered_position` and `view_move`.
.. and use it within src/config/rcxml.c and src/menu/menu.c.
This fixes being unable to use the `direction` argument in menu entries.
Reported-by: mahk via IRC
Adds two new theme vars:
- menu.width.min (menu will never be smaller than this)
- menu.width.max (menu will never be wider than this + padding)
A fixed menu width can be achieved by setting
menu.width.min == menu.width.max.
- Store a pointer to the `struct view` in `struct ssd`
- Pass `struct ssd *` instead of `struct view *` to ssd functions
- Add `ssd_get_margin()` convenience function
- Minimize includes in `ssd.h`
- Avoid repetitive `view->ssd.margin` pattern
- Use `struct ssd *` or `const struct ssd *` rather than `struct view *`
where convenient
Part of the motivation is to make it easier to separate `struct ssd`
from `struct view` in a future commit.
- Add `active` argument for consistency with `ssd_set_active()`
- `assert()` that `ssd_create()` is not called twice without an
`ssd_destroy()` in between
Gather related logic from `reload_config_and_theme()` in `server.c` and
`ssd_reload()` in `ssd.c` into a new function, `view_reload_ssd()`.
Also drop the `view->mapped` check since we want to update any view that
has SSD nodes created, mapped or not.
Add xdg_surface_from_view() + xwayland_surface_from_view() accessors
that assert() the view is of the expected type before returning.
Fix a real bug in xdg.c parent_of() that dereferenced
`view->xdg_surface->toplevel` without first checking `view->type`.
The goal of the new accessors is to catch similar bugs in future.
IMHO it encourages better design (by making dependencies more obvious)
to have source file/header file pairs like view.c/view.h, rather than a
monolithic header like labwc.h with everything in it.
I don't think we need to break up all of labwc.h at once, but maybe we
can start pulling it apart bit by bit as it's convenient.
Also:
- Move "struct border" to ssd.h so that view.h can use it without pulling
in all of labwc.h.
- Add a missing required #include within scaled_font_buffer.h (forward
declaration of "struct font" is not enough).
Currently, snapping to a screen edge and then snapping to maximize
results in both the natural_geometry and tiled state of the view
getting messed up. After unmaximize, the view ends up in a weird
state (tiled location but natural/untiled size).
There are also a couple of sketchy things going on in the code:
- interactive_begin() pokes its own values into view->natural_geometry
to force view_maximize() to set a particular geometry.
- interactive_end() "fixes" view->natural_geometry after calling
view_maximize() to save the original geometry from the start of the
interactive move/resize.
To fix all this:
- Adjust/expand the API of view.c so that the interactive.c can
avoid this "back door" of overwriting view->natural_geometry
directly.
- Save the natural geometry and the tiled state of the view in
interactive_begin() when starting to move the view. When done,
interactive_end() will update the tiled state if appropriate but
*not* overwrite the natural geometry.
It seems that every Wayland client is expected to implement its own
key-repeat logic, rather than doing it server-side as in X11. This
means that labwc also has to implement its own key-repeat logic for
compositor keybindings.
This is a very simplistic timer-based implementation. It doesn't
attempt to synthesize accurate timestamps, and may lag depending
on system load, but it appears to get the job done.
v2: Use server->wl_event_loop
v3: Comments and formatting
...so that it can be determined what wlr_keyboard events come from.
This is required to manage virtual keyboards alongside the keyboard_group
of physical keyboards.
Key events associated with keybindings (both pressed and released) are not
sent to clients. When using wlr_seat_keyboard_notify_enter() it it
therefore important not to send the keycodes of _all_ pressed keys, but
only those that were actually _sent_ to clients (that is, those that were
not bound).
This approach is consistent with sway's implementation in input/seat.c
cffb006feb/sway/input/seat.c (L173-L175)
Fixes issue #510
If a user lets go of the modifier (e.g. alt) before the 'normal' key (e.g.
tab) when window-cycling, we do not end the cycling until both keys have
been released. If we end the window-cycling on release of the modifier
only, some XWayland clients such as hexchat realise that tab is pressed
(even though we did not forward the event) and because we absorb the
equivalent release event it gets stuck on repeat.
Just to clarify the position here: Issue #176 describes a behaviour
whereby dmenu gets stuck on repeat after being launched with a keybind.
This patch does not resolve that issue but reflects that in Wayland, the
client is responsible for implementing "key repeat".
Changing the key repeat rate/delay in (labwc/labwc@e62bb51) was dirty fix
that need should never have been made.
This fixes an issue with the wlr_output_cursor not being properly
initialized on new outputs, because wlr_output_layout.events.change
is triggered too soon, before the wlr_output_cursor exists.
