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
Chases: 756ecf8ee9f1e75bc7b8297dc84f97c7d699174b
backend/wayland: use request_state when toplevel is resized
Chases: 3ef68a484243555b020200c6f95246d994932c3f
backend/x11: use request_state when window is resized
Ref: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2693
We now delay requested resolution changes by the backend until
the next frame event which causes us to render the new content
on the already enlarged buffer. Before this change, an empty
(black) buffer would have been shown instead before the next
frame event caused a new render of the actual contents.
Keep commiting the new state and then scheduling a frame event
would not help as due to the commit call it would still show an
empty buffer in the meantime.
Just modifying wlr_output->pending wouldn't work either because
wlr_scene_output_commit() *completely* ignores it (and it will
be removed in future wlroots commits). For this reason we move
to wlr_scene_output_build_state() directly because it allows us
to supply the current wlr_output->pending state and thus apply
any resolution change in lockstep with new rendering. Result:
No more flickering in the wayland backend and resizing is again
smooth as butter.
This prevents constant flicker while resizing
when running nested via the wayland backend.
For the X11 backend (can be tested via `WLR_BACKENDS=x11 labwc`),
it is still rather janky but at least doesn't cause endless self-
resizing anymore.
...<command> argument (but still resolve tilde).
This makes it easier to write sh -c '' constructs without turning labwc
into a shell parser in order to expand environment variables, whilst
respecting single quotes and escaped characters as well as ignoring
subshells syntax like $(foo) and backticks.
Also, fix bug where buffer length+alloc get out-of-sync
Two types of window rules are supported, actions and properties. They are
defined as shown below.
<windowRules>
<!-- Action -->
<windowRule identifier="some-application">
<action name="Maximize"/>
</windowRule>
<!-- Property -->
<windowRule identifier="foo*" serverDecoration="yes|no"/>
</windowRules>
Rules are applied if windows match the criteria defined by the
'identifier' attribute which relates to app_id for native Wayland windows
and WM_CLASS for XWayland clients.
Matching against patterns with '*' (wildcard) and '?' (joker) is
supported.
Add 'serverDecoration' property.
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.
This defaults to 1024, which is tiny, but is a requirement
for processes using the deprecated `select` function.
We must reset this back whenever we fork to start a new process,
as this is inherited, and breaks applications using `select` otherwise.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
