This introduces an optional "direction" argument to the Resize action,
mirroring Fluxbox's StartResizing [corner] behavior.
Supported values (case-insensitive) are:
up-left, up, up-right, left, right, down-left, down, down-right.
If no direction is specified, the existing behavior is preserved and the
resize edges are inferred from the current pointer position. The action
documentation has been updated to describe the new argument.
We were using the word "osd" to describe the window switcher, but it can
be used with on-screen display (OSD) disabled by
`<windowSwitcher><osd show="false">`. Let's use "cycle" instead to avoid
confusion.
...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>
This patch adds `combine` argument to (Toggle)SnapToEdge actions.
This allows to snap a window to e.g. up-left by running two actions:
- `<action name="SnapToEdge" direction="left" combine="yes" />`
- `<action name="SnapToEdge" direction="up" combine="yes" />`
Then running `<action name="SnapToEdge" direction="down" combine="yes" />`
snaps it to left again. This behavior is almost the same as KWin, except
that snapping a up-right-tiled window to right doesn't move it to the
right-adjacent output, but makes it right-tiled first.
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.
I like the new common/edge.h. I don't like how inconsistently we use it.
Current situation:
- enum wlr_edges and wlr_direction are designed to be used as bitset,
and are defined compatibly
- enum lab_edge is *also* designed to be used as bitset, but
incompatible with the others (LEFT/RIGHT come before UP/DOWN)
- we use an inconsistent mix of all three *AND* uint32_t (usually with
the WLR_EDGE constants rather than the LAB_EDGE constants), and
convert between them on an ad-hoc basis, sometimes implicitly
Let's clean this up:
- reorder enum lab_edge to be compatible with the two wlr enums
(check this by static_assert)
- use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges)
- add constants for the remaining possible combinations of the 4 edges
- use lab_edge for all internal edge/direction fields, consistently
- add lab_edge_is_cardinal() as a sanity check before casting to
enum wlr_direction, and then eliminate all of direction.c/h
Instead of "enum wlr_edges direction", we now have
"enum lab_edge direction" which is not that much better. At least we
are now clear that we're overloading one enum with two meanings.
Adds an option "toogle" to GoToDesktop.
In case the target is already where we are, we go back to the last desktop
instead.
Example of rc.xml
<keybind key="C-F1">
<action name="GoToDesktop">
<to>1</to>
<toggle>yes</toggle>
</action>
</keybind>
...and allow If Action without activator view.
For example:
<action name="If">
<prompt message="Toggle maximize?"/>
<then>
<action name="ToggleMaximize" />
</then>
</action>
Also revert the change in b9c84f9 that <else> branch is always taken when
no window is focused.
Co-Authored-by: johanmalm
Co-Authored-by: tokyo4j
..in preparation for If/ForEach action with <prompt>, which should be
executed whether or not any window is focused.
This patch makes <If> actions execute <else> branch if no window is
focused or hovered.
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).
Adding -Wshadow will prevent unintentional variable overrides.
Also, wrapping switch cases with declarations with braces will make our
logic more robust by limiting lifetimes of variables.
For longer cases, factor out the logic to new functions.
For very short cases, just move the declaration before the switch.
v2: in one case, replace the switch with if/else.
This removes the need to call update_client_list_combined_menu()
and update_client_send_to_menu() every time a root menu is opened.
This commit also fixed the incorrect menu position with following
configuration:
<menu id="foo" label="foo">
<item label="aaaaaa"/>
<item label="bbbbbb"/>
</menu>
<menu id="root-menu">
<menu id="foo" />
<menu id="foo" />
</menu>
Previous commits fixed some unexpected behaviors when ShowMenu action is
executed from menu items, but that was still prone to bugs because when
calling actions_run(), we allow an inconsistent state where all menus are
closed but pipemenus must not be destroyed.
So this commit simply removes ShowMenu actions from menu items on
initialization.
Before this commit, keystrokes were interpreted based on following
hard-coded rules while the window switcher is active:
1. Up/Left arrow keys cycle the window forward.
2. Down/Right arrow keys cycle the window backward.
3. Other keystrokes cycle the window in the initial direction specified
by NextWindow/PreviousWindow actions. But while Shift key is pressed,
the direction is inverted.
...and keybind actions were never executed.
However, this lead to a counter-intuitive behavior for new, especially
pre-Openbox users. For example, in the following keybinds, after the user
activates the window switcher with Super+n, Super+p cycles the window
_forward_:
<keybind key="W-n">
<action name="NextWindow" />
</keybind>
<keybind key="W-p">
<action name="PreviousWindow" />
</keybind>
This is because the key 'n' is recognized just as a normal key in the
third hard-coded rule.
So this commit changes the rules to be more Openbox-like:
1. Up/Left arrow keys cycles the window forward.
2. Down/Right arrow keys cycles the window backward.
3. Other keystrokes are matched against keybinds and execute their
actions. If they include NextWindow/PreviousWindow action, it cycles
the selected window forward/backward even while the window switcher
is active.
The previous revert fixed the problem of stuck modifier keys with
keybinds in Blender, but made Firefox show its menu bar with Alt-*
keybinds. This is fundamentally inevitable due to the limitation of
wayland protocol, but at least for the default Alt-Tab keybind for
window switcher, we can mitigate this problem by clearing the keyboard
focus when the window switcher is activated. This is what KWin does, and
we decided to follow that.
So in this commit, keyboard and pointer focus are temporarily cleared
while Move/Resize, window switcher and menu interactions and restored
after them. We slightly deviate from KWin as KWin doesn't clear the
keyboard focus while Move/Resize, but it solves our existing problem
that Firefox shows its menu bar after dragging it with default Alt-Drag
mousebind, and this is what Mutter does.
We considered other solutions, but they don't work well:
1. Send wl_keyboard.{leave,enter} every time keybinds/mousebinds are
triggered. This solves the Firefox's menu bar problem, but that
sounds like a workaround and sending unnecessary events every time is
not desirable.
2. Send release events for both modifiers and keys even when they are
bound to keybinds. This is what Mutter is doing, but it looks like an
implementation issue and violates wayland protocol.
This is reland of 2ade6a1e which was reverted with 21bd5b00, but this
prevents the x-position of the menu from being negative and slides menus
opened with Alt-Space too.
Prior to this commit, output-relative coordinate was passed to
menu_open_root() as the menu position when it's designated via "x"/"y"
arguments in ShowMenu action, so menu can be misplaced to the output other
than the one in which the cursor is in.
With 2ade6a1, negative x-values can be passed to menu_configure() when the
window menu is opened from top-left button in a maximized window, but
wlr_output_layout_output_at() couldn't find the output for the coordinate
since it's out of the output layout, thus it just opened the menu without
updating its position.
As the next release is close and the visual improvement by 2ade6a1 is not
very impactful for UX, let's revert it for now.
This commit slides menus opened from buttons (with atCursor="no") to the
left by menu.border.width. This makes the location of the window menu
look more natural, especially when it's opened from the window icon in
the left corner of the titlebar.
Prior to this commit, a menu opened with:
<action name="ShowMenu">
<position x="center" y="center" />
</action>
was not correctly centered when menu.items.padding.x is non-zero.
