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.
scaled_rect_buffer is an implementation of scaled_scene_buffer and shows
an auto-scaling bordered rectangle. This is intended for menu borders,
but can be also useful for other elements like window switcher items.
We will support rounded corners for scaled_rect_buffer in the future.
When the output is in the process of being enabled, but the new state
has not been committed yet, wlr_output->enabled is still false. So it's
not safe to assert that it's true in output_enable_adaptive_sync().
Fixes: 36e099fc93
"view: ensure output is usable before setting adaptive sync"
Implementers can define impl->equal() which compares two
scaled-scene-buffers so that buffers are not allocated for visually
duplicated scaled-scene-buffers.
Currently this mechanism isn't applied for scaled-font-buffers since we
haven't defined impl->equal() for it.
This allows implementations of the interface to share a single
wlr_buffer for multiple wlr_scene_buffer nodes and still make
the scaled-scene-buffer handle the buffer drops.
wlr_scene_buffer holds an implicit lock while using a wlr_buffer
and scaled-scene-buffer.c holds additional locks for as long as
a buffer is within its internal cache.
This should ensure that a shared wlr_buffer never gets actually
dropped even if wlr_buffer_drop() has been called by another
scaled-scene-buffer instance using the same wlr_buffer.
