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.
Filled/outlined rectangles shown as snapping overlay are now enabled/disabled
independently with `snapping.overlay.[region|edge].bg.enabled` and
`snapping.overlay.[region|edge].border.enabled`.
To keep the default behavior, `*.bg.enabled` is yes and `*.border.enabled` is
no for hardware-based renderers, while `*.bg.enabled` is no and
`*.border.enabled` is yes for software-based (pixman) renderer.
Users can now use a filled rectangle as an overlay even with pixman renderer.
However, this may severely impact performance when used with translucent
`snapping.overlay.[region|edge].bg.color`.
This commit includes a refactor to use substruct `theme_snapping_overlay`
inside `theme` in order to pass it to `create_overlay_rect()` in a cleaner way.
Breaking changes is:
- `snapping.overlay.[region|edge].fill` is now removed.
Replace "preview" in rc.xml and themerc with "overlay" since "preview" sounds
like it shows the window content.
Breaking changes are:
- `snapping.preview.*` in themerc is now replaced with `snapping.overlay`.
- `<snapping><preview>` in rc.xml is now replaced with `<snapping><overlay>`.
Add ability to set width with percentage of monitor instead of just pixels.
With this the OSD sizes itself properly on both my 4k and 2k monitors.
example: 50% or 75% instead of 600, max 100%
wlr_scene_rects expect their color to be pre-multiplied
while cairo_set_source_rgba() expects them to not be
pre-multiplied. With this patch we now use premultiplied
colors internally by default and then reverse it when
setting cairo colors.
This ensures the titlebar uses a consistent color in case
it was defined with some transparency by the user.
Fixes: #1684
Add the -m|--merge-config command line option to iterate backwards over
XDG Base Dir paths and read config/theme files multiple times.
For example if both ~/.config/labwc/rc.xml and /etc/xdg/labwc/rc.xml
exist, the latter will be read first and then the former (if
--merge-config is enabled).
When $XDG_CONFIG_HOME is defined, make it replace (not augment)
$HOME/.config. Similarly, make $XDG_CONFIG_DIRS replace /etc/xdg when
defined.
XDG Base Dir Spec does not specify whether or not an application (or a
compositor!) should (a) define that only the file under the most important
base directory should be used, or (b) define rules for merging the
information from the different files.
ref: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
In the case of labwc there is a use-case for both positions, just to be
clear, the default behaviour, described by position (a) above, does NOT
change.
This change affects the following config/theme files:
- rc.xml
- menu.xml
- autostart
- environment
- themerc
- themerc-override
- Theme buttons, for example max.xbm
Instead of caching global config/theme directories, create lists of paths
(e.g. '/home/foo/.config/labwc/rc.xml', '/etc/xdg/labwc/rc.xml', etc).
This creates more common parsing logic and just reversing the direction
of iteration and breaks early if config-merge is not wanted.
Enable better fallback for themes. For example if a particular theme does
not exist in $HOME/.local/share/themes, it will be searched for in
~/.themes/ and so on. This also applies to theme buttons which now
fallback on an individual basis.
Avoid using stat() in most situations and just go straight to fopen().
Fixes#1406
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.
...so that svg and png icons only support the max_toggled_hover format.
There is no need to support max_hover_toggled because there are no
backward compatibility considerations as Openbox does not handle png and
svg icons.
...and treat max_hover_toggled.xbm as an alternative name supported for
compatibility reasons.
Use the following button filename schema: "BUTTON [TOGGLED] [STATE]"
with the words separted by underscore and with the following meaning:
- BUTTON can be one of 'max', 'iconify', 'close', 'menu'
- TOGGLED is either 'toggled' or nothing
- STATE is 'hover' or nothing.
This is consistent with the openbox.org wiki and it is believed that this
is how the vast majority of extant openbox themes out there are written.
But please be aware that it is actually different to vanilla Openbox which
uses: "BUTTON [STATE] [TOGGLED]" following a commit in 2014 which broke
themes and led to some distros patching Openbox:
35e92e4c2a
Arch Linux and Debian patch Openbox to keep the old syntax (the one that
this commit aligns us with).
https://gitlab.archlinux.org/archlinux/packaging/packages/openbox/-/blob/main/debian-887908.patch?ref_type=heads
...and change default values for the variables below to keep the
window-switcher look the same as it was at the last release.
osd.window-switcher.padding = 4
osd.window-switcher.item.padding.y = 1
osd.window-switcher.item.active.border.width = 2
...by reading <config-dir>/themerc-override where <config-dir> is normally
$HOME/.config/labwc can be other locations as described in labwc-config(5)
and can also be specified by the command line option -C.
The reason for supporting theme override is to give users more fine-
grained control of settings without making local copies and modifying
themes.
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.
