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.
Behaves identical like SnapToEdge and SnapToRegion, but
untiles the window when already being tiled to the given
region or direction.
Co-authored-by: tokyo4j <hrak1529@gmail.com>
Before this commit, we assumed `ShowMenu` action is not bound to any
buttons other than window menu button and always place the client-menu
under the window-menu button when atCursor="no". Also, it was going to be
difficult to distinguish whether the action is executed from the window
menu button or the window icon, which will be added soon.
This commit fixes it to open the menu under the actually-clicked button by
passing `cursor_context` to `actions_run()`, with some refactoring:
- `seat->pressed.resize_edges` is removed and it's calculated from the
cursor position and `seat->pressed.type` just before running Resize
action. This slightly changes the existing logic to determine the
resizing edges with Alt-Right + Drag mousebinding, but
`seat->pressed.type` is still stored on button press so it doesn't bring
back the issue #543.
- `seat->pressed.toplevel` is removed and `get_toplevel()` in
`update_pressed_surface()` may be called more often, but its overhead
will be negligible.
Shows all workspaces that current view can be sent to.
Works best when added to Client menu.
<menu id="client-send-to-menu" label="Send to..." />
Menu uses ">" and "<" to highlight the current workspace
We don't know if the client-list-combined-menu is standalone
ie. triggered by a keybind or a submenu of another menu.
So we update client-list-combined-menu every time ShowMenu is called.
It looks slightly awkward when the client menu shows up
in the left corner of the view and the window menu button
is configured to be on the right side.
...utilizing x,y coordinates where values can be a number, a negative
number, a percentage or "center".
- (0,0) is top left corner
- (-0,-0) is bottom right corner
- % is percentage of width and/or height
- 'center' centers the menu vertically and/or horizontally
<action name="ShowMenu">
<menu>root-menu</menu>
<position>
<x>0</x>
<y>0</y>
</position>
</action>
Note: both x and y values must be supplied for positioning to work.
