Clients can ignore the requsted geometry and negative widths could be
passed to `wlr_scene_rect_set_size()` in `ssd_titlebar_update()` or in
`ssd_border_update()`.
Add optional drop-shadows to windows using server-side decoration.
Shadows can be enabled/disabled rc.xml and their appearance configured
in themerc. The default is no shadows to preserve current behaviour.
The shadows are drawn in fixed corner and edge buffers shared between
all windows, the edges are scaled to size depending on the size of each
window. Two sets of buffers are used to give the different appearances
for active and inactive windows. I use separate corner/edge buffers for
a few reasons:
- It avoids needing to store a separate large shadow buffer per window
- It avoids needing to redraw the shadows when the window is being
resized
- Compositing the shadows onto the desktop should be faster as there are
overall fewer pixels to blend, and scaling up the edge buffers only
requires reading a tiny buffer which is then replicated.
This fixes an issue detected by the static analyzer.
It currently is not a real bug but it could become
one in the future if `add_toggled_icon()` is called
before `add_scene_button()`.
Rather than having `add_toggled_icon()` go through
the list, find the root button and then fetch its
node descriptor just supply the button as argument.
After a roundabout discussion[1] with wlroots devs, it's become apparent
that subpixel text rendering (a.k.a. "ClearType") does not work properly
when rendering over a transparent background, as labwc currently does.
Basically it comes down to the fact that the color of semi-transparent
pixels (which is adjusted redder or bluer to compensate for RGB subpixel
alignment) depends somewhat on background color. When rendering over
transparency, the text engine doesn't know the intended background color
and can't adjust the pixel colors correctly.
With Pango/Cairo, the end result can range from grayscale rendering (no
subpixel rendering at all) to wrong/oversaturated colors (for example,
bright pink pixels when rendering white text on blue background).
This change solves the issue by first filling the text buffer with an
opaque background color before rendering the text over it. Currently,
this is easy since the background is always a solid color. It may be a
little more complex (but doable) if we implement gradients in future.
Note that GTK 4 (and to some degree, recent versions of Microsoft
Windows) avoid this issue by disabling subpixel rendering altogether. I
would much prefer that labwc NOT do this -- it results in noticeably
blurrier text on non-retina LCD screens, which are still common.
[1] https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3822
This uses the new `view->outputs` bitset to calculate the intersection
with *all* outputs the view is currently visible on.
This ensures that the invisible resize handle works across outputs
while still making sure that it won't leak into neighboring ones just
because it is positioned closely to an output edge (either manually,
maximized or snapped via SnapToEdge or SnapToRegion).
Co-Authored-By: @johanmalm
Fixes: #1486
Reported-By: @lurch
This builds on the work of @Consolatis in #1018.
Co-authored-by: Consolatis <35009135+Consolatis@users.noreply.github.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
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.
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
For views with a non-pixel size increment (e.g. X11 terminals), it's
helpful to subtract the base size of the window (typically including
menu bar, scrollbars, etc.) before computing the number of size
increments (e.g. cells/characters). This way, the displayed size will
exactly match the terminal grid (e.g. 80x25 or whatever).
wlr_box isn't really the best fit for size hints, so let's define a
struct view_size_hints and a nice view_get_size_hints() function,
wrapping view->impl->get_size_hints().
This also seems like a great opportunity to make view_adjust_size()
window-system-agnostic and eliminate xwayland_apply_size_hints().
Before this patch we were using the internal .enabled flag of the titlebar
tree node. This failed due to ssd_thickness() not having view->ssd assigned
when initially called. Instead of assigning view->ssd within ssd_create()
we just always use the view boolean flag directly. This fixes an issue
where a border-only view that has been snapped to an edge or region would
have a gap in the size of the titlebar on top after a Reconfigure.
Fixes#1083
The previous PR introduced an issue with tiling based actions
like SnapToEdge and SnapToRegion using outdated SSD margin
values when called via keybind while maximized. That resulted
in wrong offsets for the tiled windows.
This commit restores the functionality by forcing a re-calculation
of the SSD margin when changing the maximized state.
Thanks to @Flrian for reporting the issue via IRC.
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
wlr_output_layout_get() returns NULL for disabled outputs.
Backtrace (abbreviated):
#0 lab_wlr_output_layout_layout_coords at ../src/ssd/ssd_extents.c:33
#1 ssd_extents_update at ../src/ssd/ssd_extents.c:133
#2 ssd_extents_create at ../src/ssd/ssd_extents.c:95
#3 ssd_create at ../src/ssd/ssd.c:161
#4 decorate.part.0.lto_priv.0 at ../src/view.c:637
#5 decorate at ../src/view.c:636
#6 view_set_fullscreen at ../src/view.c:716
#7 view_adjust_for_layout_change ../src/view.c:745
#8 desktop_arrange_all_views ../src/desktop.c:52
#9 output_update_all_usable_areas at ../src/output.c:495
#10 output_update_for_layout_change at ../src/output.c:263
#11 do_output_layout_change at ../src/output.c:423
#12 do_output_layout_change at ../src/cursor.c:267
#13 output_config_apply at ../src/output.c:334
#14 handle_output_manager_apply at ../src/output.c:354
This allows using large XBM button icons (larger than
the button width / height) for high and mixed DPI usecases.
Instead of scaling up the low pixel icons when moving a window to a
high DPI output we scale the icons down when moving to a non-scaled
output. The user is still responsible to create / use larger XBM
icons for their theme.
Partly fixes#609
- 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.
- 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.
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).
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.
