Removing newlines in rc.xml and menu.xml caused parser error with
following content:
<!--
-
- Some comments
-
-->
...though it is a valid XML.
Let's not do that. I moved `grab_file()` to `buf.c` and renamed it to
`buf_from_file()`, because it now directly touches `struct buf` and
I don't like having a source file only for one function.
...to enable configuration of the action prompt command.
Also set some better defaults for labnag.
The new default command is:
labnag \
--message '%m' \
--button-dismiss '%n' \
--button-dismiss '%y' \
--background '%b' \
--text '%t' \
--border '%t' \
--border-bottom '%t' \
--button-background '%b' \
--button-text '%t' \
--border-bottom-size 1 \
--button-border-size 3 \
--timeout 0
...where the conversion specifiers are defined as follows:
%m: the `<prompt>` message option
%n: _("No")
%y: _("Yes")
%b: osd.bg.color
%t: osd.label.text.color
This config options also enables the use of a different dialog client, for
example like this:
<core>
<promptCommand>zenity --question --text="%m"</promptCommand>
</core>
These are just lists of enum lab_node_type, with a bounded size and
no middle-insertions/removals, so linked lists are overkill.
Also, the use of wl_list_for_each[_reverse] just to access the first or
last entry in the list (corner button) was weird.
ssd_part_type contains several node types that are not actually part of
server-side decorations (ROOT, MENU, OSD, etc.)
Rename it accordingly and move it to a common location, along with some
related conversion/comparison functions.
Our codebase for ssd scenes has grown with a lot of technical debts:
- We needed to call `ssd_get_part()` everywhere to get the scene node of a
ssd part. We then needed to cast it to `wlr_scene_rect` and
`wlr_scene_buffer`. This bloated our codebase and even blocked
duplicated button types in `<titlebar><layout>`.
- `ssd_get_part_type()` was a dirty hack. It compared parent, grandparent
and grandgrandparent of a node with each subtree in the ssd to get the
part type of the node.
To resolve this issues, this commit changes how ssd scenes are managed:
- Access scene rects and scene buffers just as a member of `struct ssd`.
- `ssd_part` is now a attachment to a scene node that can be accessed via
node_descriptor->data, with a new node-descriptor type
`LAB_NODE_DESC_SSD_PART`. `LAB_NODE_DESC_SSD_BUTTON` is unified into it.
Now the scene graph under ssd->tree looks like below. The parentheses
indicate the type of ssd_part attached to the node:
ssd->tree (LAB_SSD_NONE)
+--titlebar (LAB_SSD_PART_TITLEBAR)
| +--inactive
| | +--background bar
| | +--left corner
| | +--right corner
| | +--title (LAB_SSD_PART_TITLE)
| | +--iconify button (LAB_SSD_BUTTON_ICONIFY)
| | | +--normal close icon image
| | | +--hovered close icon image
| | | +--...
| | +--window icon (LAB_SSD_BUTTON_WINDOW_ICON)
| | | +--window icon image
| | +--...
| +--active
| +--...
+--border
| +--inactive
| | +--top
| | +--...
| +--active
| +--top
| +--...
+--shadow
| +--inactive
| | +--top
| | +--...
| +--active
| +--top
| +--...
+--extents
+--top
+--...
When hovering on SSD, `get_cursor_context()` traverses this scene node
from the leaf. If it finds a `ssd_part` attached to the node, it returns
`ssd_part_type` that represents the resizing direction, button types or
`Title`/`Titlebar`.
I needed to debug an input configuration issue and found the debug
output not-super-helpful, so I made some improvements:
- Print the name and "sysname" (e.g. event11) of the device being
configured. Note that the name alone isn't enough since there can
be multiple identically-named devices.
- Print the config category matched for each device.
- Print the config values (if any) being applied. For enums, only the
numeric value is printed since I'm lazy.
- Don't print "pointer acceleration configured" if neither a pointer
speed nor acceleration profile is configured (it's confusing).
- add LAB_WINDOW_TYPE_INVALID in place of literal -1
- document more clearly that enum lab_view_criteria is a bitset
- other one-off replacements of integer values/types for consistency
Note: variables of type enum lab_view_criteria are already used
extensively throughout the code to contain combinations of the declared
enum values. I am not introducing any new usage here, just changing the
single uint32_t to be consistent with all the other usages.
update_keycodes_iter() currently has 4(!) levels of nested loops, which
makes the logic (especially the break/continue statements) difficult to
understand. The logic also appears to continue looping uselessly after
a given keycode has already been added to a keybind.
Refactor by adding some small utility functions:
- keybind_contains_keycode()
- keybind_contains_keysym()
- keybind_contains_any_keysym()
No functional change intended.
In addition to <snapping><range>, <snapping><cornerRange> configures the
distance from the screen corner to trigger quater window snapping.
Also, new values "up-left", "up-right", "down-left" and "down-right" are
allowed for <action name="(Toggle)SnapToEdge" direction="[value]"> and
<query tiled="[value]">.
This commit rewrites the nested action parser into append_actions() which
is used by following commits. At this point, it's not used yet and parsing
"If" action is temporarily disabled.
For example, the following node:
<keybind name.action="ShowMenu" menu.action="root-menu"
x.position.action="1" y.position.action="2" />
is converted to:
<keybind>
<action>
<name>ShowMenu</name>
<menu>root-menu</menu>
<position>
<x>1</x>
<y>2</y>
</position>
</action>
</keybind>
...before processing the entire xml tree. This is a preparation to prevent
breaking changes when we refactor rcxml.c to use recursion instead of
encoding nodes into dotted strings.
This is a common practice in C projects, which simply enforces that
each header must compile cleanly without implicit dependencies on
other headers (see also the previous commit).
This revises the changes done in 22d319c:
- Cancel defaulting to <dragLock>sticky<dragLock>. So labwc now disables
drag-lock by default, as libinput does.
- Update the options from [yes|no|sticky] to [timeout|no|yes] to
emphasize that the "sticky" mode (now "yes") is recommended when using
drag-lock.
...to enable/disable primary selection clipboard support. This only works
on launch.
The reason it is useful to be able to disable this is that some clients
(like browsers) support middle-button-click to start scrolling up/down.
With some clients can be disabled via
gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false
...but for others (like chromium and electron based programs) a compositor
setting is required.
Fixes: #2815
