- 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
If `view->ssd_enabled` is false when calling `ssd_create()` then
`ssd_thickness()` returns zeroes which are stored in `ssd->margins`.
The quick fix is just to ensure we set `view->ssd_enabled` before
calling `ssd_create()`. At some point, it might be nice to refactor
so that `ssd_create()` does not reference `view->ssd_enabled`.
- 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.
- Update `ssd.state` in `ssd_create()` to avoid doing unnecessary work in
the next call to `ssd_update_geometry()`
- Reset `ssd.margin` in `ssd_destroy()` to avoid accidentally using stale
values
- 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.
`view_set_decorations()` now calls `ssd_create()` and `ssd_destroy()`
explicitly to enable/disable decorations. As a result, the implicit
enable/disable logic in `ssd_update_geometry()` is no longer needed.
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.
I was making a theme and discovered only the active window button icon
color was taking effect. The pixmaps were being created in both the
active and inactive cases, but inactive pixmaps were never added to
the SSD scene graph.
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.
map() in xwayland.c called ssd_create() but did not call
view_apply_maximized_geometry() afterward, resulting in the
decorations being displayed off-screen.
Rather than calling view_apply_maximized_geometry() in more places,
let's reuse the existing call in view_set_decorations(), and extend
ssd_update_geometry() to call ssd_create() when needed.
Previously mosuebinds for the same context using the same button
but different modifiers would be merged, e.g. only the last one
would survive the merge. This commit adds the missing check for
keyboard modifiers.
Fixes#630
Reported-by: @lidgnulinux
This ensures that those surprised by the deprecation of SUID operation
receive an error rather than accidentally having run as root.
swaywm/sway@e572805
Mouse bindings, unlike key bindings, are made within contexts which
represent what was clicked/dragged. The context 'Frame' refers to the
entire window frame including both the window decorations (if any) and the
client window itself. It is typically used for alti + left/right click to
move/resize the window.
'Frame' is a special case in that when a button is bound in this
context, the action will not be forwarded to the client, which is what
we describe with the 'consumed_by_frame_context' variable.
