This allows to use it for a future ext-workspace implementation.
It is also more generalized so can be used for other protocol
implementation in the future in case the protocols require some
kind of transaction management.
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.
This is a compile-time check, so it will be too conservative if somebody
updates wlroots after building labwc, but that is still better than the
alternatives.
Simple utility to allow protocol and version comparison between different
running compositors. This can be used to detect missing protocols or
versions in labwc. See for example this result when running against the
current labwc master and sway 1.10 (nested, results on DRM may differ):
Protocols missing from labwc @ wayland-0
ext_transient_seat_manager_v1 1
wl_compositor 6 (has version 5)
wp_alpha_modifier_v1 1
wp_content_type_manager_v1 1
xdg_wm_base 5 (has version 3)
zwp_keyboard_shortcuts_inhibit_manager_v1 1
Protocols missing from sway @ wayland-1
wl_drm 2
zcosmic_workspace_manager_v1 1
...to avoid a bug that is present in wlroots <0.18.2 and which has the
potential to crash the compositor when performing a drag-and-drop action
at the same time as the XWayland server is shutting down.
This will be reverted when wlroots-0.18.2 can be linked with.
Related-to: #2371
...when options are specified as elements leading to hitting the assert()
in xstrdup().
Reproduce by using this rc.xml:
```
<?xml version="1.0"?>
<labwc_config>
<touch>
<deviceName>foo</deviceName>
<mapToOutput>bar</mapToOutput>
</touch>
</labwc_config>
```
It is likely that <touch> was only tested with options as attributes.
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.
In the longer term we want this to be user-configurable (and also depend
on the sandbox engine, app_id and instance).
But dropping privileged protocols for sandboxed clients in the meantime
seems like a sensible thing to do and matches user expectations.
Related: #2392
set_squared_corners(false) was always called when titlebar is created.
However, set_squared_corners(false) sets the width of the titlebar
background buffer to (view width) - (corner radius), which causes pixman
errors due to the negative width set for titlebar background buffer when
the view is so small.
...of modifiers which are part of keybinds. This supports clients (for
example blender) that want to see modifier-release-events even if they are
part of a keybinds.
Most clients (including those using Qt and GTK) are setup to not see these
modifier release events and actually misbehave if they do. For example
Firefox shows the menu bar if alt is pressed and then released, whereas if
only pressed (because the release is absorbed) nothing happens. So, if
Firefox saw bound modifier-release-events it would show the menu bar every
time the window-switcher is used with alt-tab.
<windowRules>
<windowRule identifier="blender" wantAbsorbedModifierReleaseEvents="yes"/>
</windowRules>
Issue #1507
Since GitHub runners now support hardware virtualization,
the maximal runtime of the FreeBSD runner is somewhere
around 3 to 6 minutes. It may still fail sometimes so
keep the timeout parameter around.
lab_data_buffer->logical_{width,height} are not the actual size of the
backing buffer, so wlr_buffer.{width,height} should be used when
duplicating it in get_cairo_surface_from_lab_data_buffer().
This mistake caused segfault when an icon file 1~2 times larger than
window.button.{width,height} is loaded, because the buffer for the raw
icon file is reused by setting lab_data_buffer->logical_{width,height}
with the size for display which is different from
wlr_buffer.{width,height} (see buffer_convert_cairo_surface_for_icon()),
and it is duplicated with get_cairo_surface_from_lab_data_buffer() for
hovered/rounded variants of titlebar button.
It was a cruft from my experiment of adding borders around titles.
It even caused an integer overflow because theme->menu_border_width can be
INT_MIN when menu_header_height is calculated.
This makes the colors of titlebar and window borders different, but will
let menu.border.color (which will be supported soon) inherit
window.active.border.color just like Openbox does, without making the menu
borders around a selected menu item invisible.
