server->menu_current should be cleared before calling actions_run() as
it may internally call menu_open_root(). Clearing it after actions_run()
leads to an inconsistent state where a menu is opened but
server->menu_current is NULL. It even lead to a segfault when the item
opening another menu is contained in a pipemenu, because
menu_open_root() calls destroy_pipemenu() when server->menu_current is
set, which makes accessing item->actions a UAF.
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 commit delegates the calculation for menu position into wlroots
utilities for xdg_positioner.
Notable functional changes are:
- Slide the menu to fit in the output when it's opened out of the output
(e.g. top-left window menu is opened when the window is overflowing to
the left), rather than not updating the menu at all.
- The horizontal alignment of menus is now determined based on the size of
each (sub)menu alone rather than the total width of entire menu tree.
This means submenus can now overlap with is parents, but this is no
longer a problem since we recently added support for menu borders.
- Fixed that pipemenus always follow the alignment of its parent even when
it overflows from the output.
Arrow signs are specific to submenu items, so they would be more natural
to be handled in menu.c rather than accepting "arrow" in
font_buffer_create().
Also I allowed non-positive numbers for max_width in font_buffer_create(),
in which case the natural font width is used as the buffer width.
- Don't store font/background buffers in menuitem struct since we no
longer dynamically update buffers of existing menuitems.
- Factor out the duplicated codes for creating menu item scenes for each
unselected/selected states.
I missed that `scaled_font_buffer_update()` has `max_width` argument and
the subsequent calls to `scaled_font_buffer_set_max_width()` caused
unnecessary re-renderings.
This fixes use-after-free when there's only 1 desktop and
menu_hide_submenu() is called to delete "Workspaces" submenu in
client-menu before menu scenes are initialized.
As menu_create() and item_create() no longer initialize scenes after
76515316, menu->scene_tree and item->tree should be null-checked.
The deleted lines were dead code that didn't make any sense (even if it
were not dead, it should have recreated the parent of the hidden menu
rather than the hidden menu itself).
Commit 7651531 introduced a regression: `menu_update_scene()` which
re-creates a menu scene was called for all the menus when a pipemenu is
created, so the menus (parent of the pipemenu) were always moved to (0,0)
and hidden, and the pipemenu was incorrectly positioned.
This commit fixes it by calling `menu_update_scene()` only for the
pipemenu when it's created.
This commit separates the process of creating scene-trees of the menu
items into `{item,separator,title}_create_scene()`. This will make it
easier to draw richer menu designs like borders, paddings and rounded
corners.
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
...defined by `<separator label="">`.
Also add the theme option `menu.title.bg.color: #589bda`
The following will be added in separate commits
- menu.title.bg.border.color: #7cb6ec
- menu.title.text.color: #ffffff
- menu.title.text.justify: center
...such as the one in the example below:
<?xml version="1.0" encoding="UTF-8"?>
<openbox_menu>
<menu id="root-menu" label="obmenu-generator" execute="obmenu-generator"/>
</openbox_menu>
We should consider supporting this construct in future.
Reported-by: cry0xen via IRC
