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
With the new keepBorder option enabled, the
ToggleDecorations action now has 3 states:
- the first time only disables the titlebar
- the second time disables the whole SSD
- the third time enables the whole SSD again
When the keepBorder action is disabled, the old 2-state
behavior is restored, e.g. the ToggleDecorations action
only toggles between on and off.
Fixes#813
- 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.
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).
Before this commit the window title could overflow in certain conditions,
usually when rapidly resizing. This commit fixes it by completely hiding
the corresponding scene node when there is no space available.
Reported-by: <peperino> via IRC
This matches the behavior of the surrounding borders and will usually
cause resizing instead of triggering the button itself. This effect
is only really visible when using a border width settings of > 1.
Fixes#379
As it turns out the reason for the workaround was a bug
in wlroots which got fixed in the meantime.
So to keep things simple just revert the workaround and
depend on the wlroots fix instead.
To update the wlroots subproject use
meson subprojects update wlroots
This reverts commit e87aa19066.
wlr_scene_buffers need an additional wlr_scene_buffer_set_source_box()
to be scaled correctly by wlroots based on the output scale.
With this commit the buffers are now scaled correctly but, especially
on higher scale factors, may be a bit blurry.
In the future we likely want a dynamic font label generator based
on the maximal scale of all the outputs the specific buffer is currently on.
Some inspiration for that could be
https://github.com/Nefsen402/sway/blob/scene-graph/sway/sway_text_buffer.cFixes#348
