...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`.
- 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.
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
Before this commit, all <field> entries inside different <fields> entires
were inserted to the same list. Suppose we have following configuration:
<windowSwitcher>
<fields><field content="title" width="100%" /></fields>
</windowSwitcher>
<windowSwitcher>
<fields><field content="identifier" width="100%" /></fields>
</windowSwitcher>
In this case, both two <field> entries were inserted to
rc.window_switcher.fields, making the OSD content overflow.
This commit fixes by clearing rc.window_switcher.fields when the parser
encounters <windowSwitcher><fields>.
