This fixes the ugly look of SSD for tiny windows (e.g. "xterm -geometry
1x1") due to the early return in `ssd_update_geometry()`. Now SSDs are
rendered correctly for those windows by hiding some buttons when the
window width is smaller than the total width of buttons. Additionally for
windows smaller than (button width)*2, the corners are un-rounded so a
small titlebar can be rendered with a scene-rect.
Before this commit, the backgrounds of titlebar corners were tagged as
LAB_SSD_PART_CORNER_TOP_{LEFT,RIGHT}, so the cursor shape on titlebar
corners without buttons were north-west or north-east.
This commit fixes it by tagging those backgrounds as
LAB_SSD_TITLEBAR_CORNER_{LEFT,RIGHT}.
Before this patch, we were leaking memory [0] because the
shadow implementation did not free the ssd_parts on destruction.
There was also no check if shadows were actually enabled via
rc.xml or not so this also impacted people who were not using
shadows but were not setting the shadow size via their theme to 0.
[0] 44 bytes per ssd_part * 8 parts * 2 states == 704 bytes per
view closed. Note that Reconfigure also re-creates the SSD, thus
we were also leaking 704 bytes * nr_views per Reconfigure.
<resize><drawContents>[yes|no] configures whether to let the clients
redraw its window content content while resizing.
When <resize><drawContents> is set to no, a multi-rect is shown to
indicate the geometry of the resized window.
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
