This ensures all event listeners are removed before the emitting
wlroots object is being destroyed. This will be enforced with asserts
in wlroots 0.19 but there is no reason to not do it right now either.
This change in wlroots 0.19 is implemented via commit
8f56f7ca43257cc05c7c4eb57a0f541e05cf9a79
"Assert (almost all) signals have no attached listeners on destroy"
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>
Before this commit, nothing was rendered in window icon button if the
application doesn't set its app_id (e.g. nested kwin_wayland). This was my
oversight in dc474521.
This commit makes sure fallback icon (set via <theme><fallbackAppIcon>)
by removing ssd->state.app_id and the early-return in
ssd_update_window_icon(). This doesn't affect performance because
scaled_icon_buffer caches app_id and scaled_icon_buffer_set_app_id() does
nothing when a duplicated app_id is passed.
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.
Eliminate corner extents and instead use cursor position to map SSD
borders and extents to corner contexts, with a size configurable by the
<resize><cornerRange> parameter. This simplifies extent handling,
eliminates bugs in the detection of corner context, and allows users to
expand corner targets if they wish.
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
This commit adds <theme><fallbackAppIcon> that configures the icon name
to be used when lookups for an application icon is failed. Its default
value is set as 'labwc' which shows our labwc logo.
padding_x in lab_img_render() was just to make sure window icons in the
titlebar doesn't get too close to adjacent buttons and it didn't felt
clean. To remove it from lab_img, this commit changes the size of window
icon buffers from (window.button.width)x(window.button.height) to
(window.button.width * 0.8)x(window.button.height) and horizontally
slide it by (window.button.width * 0.1) to keep the horizontal padding.
Note that the size of the hitbox for a window icon is kept the same and
nothing is changed from user's perspective.
This prevents potential bugs that buffers created by scaled_scene_buffers
before Reconfigure are reused by other newly created scaled_scene_buffers.
This is targeted for scaled_icon_buffer whose buffer creation depends on
server->sfdo.
And make mousebind handlers use that one.
Also remove keyboard_any_modifiers_pressed() and replace its usage
with the new function.
Without this patch we would only request the modifier state of the
keyboard group which makes mousebinds involving keyboard modifiers
break for virtual keyboards like when using wayvnc. Same story for
hiding the workspace overlay or snapping to regions.
Fixes: #2511
This fixes an issue with buffers not updating when an output is configured
for a new scale. It also supports windows being on more than 2 outputs at
once and in general simplifies the code.
This patch splits desktop_entry_icon_lookup() into two separate functions
- desktop_entry_load_icon(): load a icon from the configured icon theme
- desktop_entry_load_icon_from_app_id(): load a icon name from a .desktop
file based on the given app_id and supply it to _load_icon().
The _load_icon() function will be used in a future menu icon
implementation whereas the _load_icon_from_app_id() function is used
within the SSD titlebar window icon lookup routine.
683f67b7 introduced another regression that the modifier state (Ctrl) is
stuck when Ctrl+F is pressed in some applications like Firefox while
Fcitx5 is running. This caused mouse scrolls to zoom in/out the UI.
Let me explain the cause in detail. When Ctrl+F is pressed, an input box
is opened in the application and Fcitx5 creates a new virtual keyboard
(VK), whose initial modifiers is empty. Then prior to 683f67b7, the
key/modifiers events flowed like this:
- The compositor detects F key-release
- Modifiers (Ctrl pressed) are notified via _set_keyboard()
- F key-release is forwarded to IM
- IM sends modifiers (Ctrl) back to the compositor via VK
- **The modifiers on VK is updated (empty->Ctrl)**
- **Modifers (Ctrl) are notified to the app**
- IM sends F key-release back to the compositor via VK
- F key-release is notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is forwarded to IM
- Modifiers (empty) are forwarded to IM
- IM sends Ctrl key-release back to the compsitor via VK
- Ctrl key-release is notified to IM
- IM sends modifiers (empty) back to the compositor via VK
- **The modifiers on VK is updated again (Ctrl->empty)**
- **Modifiers (empty) are notified to the app**
Thus, the final modifiers (empty) is notified to the application as
expected. However, after 683f67b7, the key/modifiers events flowed like
this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- Modifiers (empty) are forwarded to IM
- IM sends modifiers (empty) back to the compositor via VK
- **Modifier on VK is not updated (empty->empty)**
- **The compositor ignores it**
So the final modifier (empty) is never notified to the application, which
causes stuck Ctrl modifier.
This commit fixes this by not forwarding the modifiers when it hasn't been
updated since it was forwarded previously. So after this commit, the
key/modifiers events flow like this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- The modifiers are directly notified to the app because the modifiers
(empty) are the same as the last forwarded modifier (empty).
as well as 'openbox-3', for example: /usr/share/themes/foo/labwc/themerc
Give 'labwc' higher precedence than 'openbox-3' if both exist.
For several reasons not all themes designed for labwc render well on
Openbox:
1. Labwc support some features like SVG/PNG icons and #rrggbbaa color
definitions which Openbox does not.
2. Openbox generally defaults to black/white colors and will not render
themes accurate without certain options specified in themerc. For
example, in Openbox the following will just render as black:
window.active.title.bg.color: #589bda
...because Openbox defaults the texture to "Gradient Vertical" and
therefore either needs:
window.active.title.bg.colorTo: #3c7cb7
...or remove 'Gradient' from the bg definition and just use something
like:
window.active.title.bg: Flat Border
Whilst none of this is a problem when using labwc, it causes problems for
setups with both Openbox and labwc because themes designed for labwc only
will now show up in obconf, lxappearance, etc causing confusion for users.
16dbdc64 changed the padding around the app icon in the titlebar to be
applied both vertically and horizontally rather than only horizontally
because it was more natural from a developer's perspective, but some users
complained about the smaller icons in certain configurations.
So let's undo the change in 16dbdc64 and apply the icon padding only
horizontally for now.
We can add configurations for the icon padding (or icon size independent
from window.button.{width,height}?) later.
Before this commit, there was a use-after-free bug on Reconfigure:
- theme_finish() destroys lab_imgs for titlebar icons
- For some reason, undecorate() calls _create_buffer() in
scaled-img-buffer.c, which calls img_render() on a destroyed lab_img.
So in this commit, the lifetime of lab_img is expanded to when the
scaled_img_buffers referencing it are all destroyed. This is achieved by
calling lab_img_copy() when setting a lab_img to scaled_img_buffer and
calling lab_img_destroy() when clearing a lab_img.
Now that scaled_img_buffer.img are always different, lab_img_equal() is
added to compare the content of scaled_img_buffer.img.
lab_img.theme member was referenced by "modifier" functions when drawing a
hover effect on button buffers or rounding the button buffer for corner
buttons, but this can be prone to use-after-free and was not very clean
because theme and lab_img were referencing each other.
Instead, let's just reference rc.theme in the modifier functions and
remove theme from lab_img.
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.
Currently, labwc automatically enables outputs at startup and when new
outputs are connected. Make this behavior optional (but still enabled by
default).
With autoEnableOutputs disabled, tools such as kanshi can be used to
give finer-grained control of which outputs are enabled and when.
Currently we may end up in an endless loop of Reconfigure requests
if the Reconfigure action was called by a keybind. If the reconfigure
takes too long (which may happen on slow systems with libsfdo full
debug logging for example) the reconfigure might be triggered again
and again.
To prevent that, simply cancel all keybind_repeat timers on reconfigure.
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.
