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.
...when cycling windows. Also make the toggling of direction when shift
is pressed relative to the initial direction. For example if W-j is
bound to PreviousWindow, subsequent key presses will continue to
cycle backwards unless shift if pressed.
Add documentation for using shift/arrow keys in Next/Previous
This adds a screen magnifier which can be controlled with the
`ZoomIn` / `ZoomOut` and `ToggleMagnify` actions.
It scales up part of the rendered framebuffer so the magnification
may end up looking blurry depending on the magnification scale.
PR #1774
Before this patch, labwc would happily kill itself when the user
called the `Kill` action when any xwayland view had focus.
The reason this happened was that wlroots creates the xwayland
wayland client via socketpair() and thus a lookup of the pid
of the socket connection would return the pid of labwc itself.
This patch fixes that by implementing different pid lookup
mechanisms based on the view implementation backend.
Fixes: #1739
Add a BUF_INIT macro, which makes it easier to initialize a struct buf
to an empty string (without a heap allocation).
Add buf_move() to move the contents of one struct buf to another (the
source is reset to BUF_INIT, analogous to C++ move-assignment).
Use buf_reset() instead of directly calling `free(s->buf)` since the
internal buf may not always be allocated by malloc() now.
Add custom field with subset of printf style formatting
to replace the original field formats.
Example:
<windowSwitcher preview="no" outlines="no" allWorkspaces="yes">
<fields>
<field content="custom" format="foobar %b %3s %-10o %-20W %-10i%t" width="100%" />
</fields>
</windowSwitcher>
Mono space font recommended. May need OSD width adjusted
Co-authored-by: @Consolatis (based on work done by them)
