Prior to this commit, when we receive fine-grained scroll events from
touchpads that are bound to any mousebind, we leaked the scroll events to
the client unless the accumulated scroll delta exceeds the fixed threshold.
This was annoying for example when a user wants to ZoomIn/Out with
W-Up/Down mousebinds with a touchpad.
So this commit fixes it by not leaking the scroll events nor executing
actions when the accumulated delta doesn't exceed the threshold.
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).
On reconfigure, we should send wl_pointer.{leave,enter} events if the
cursor is on an application surface to let the application update the
cursor, but bad788cc prevented these events from being sent.
86c3597 raised server->menu_tree above layer shell surfaces, but it caused
preview outlines for window switcher to be placed above the OSD because
the preview outlines are placed just above server->menu_tree.
So this commit fixes it by placing server->osd_tree above server->menu.
This also prevents layer-shell surfaces from covering the OSD.
Before (higher-first):
- preview outlines (just above menu)
- menu
- layer-shell (top/overlay/popup)
- osd
After (higher-first):
- osd
- preview outlines (just above menu)
- menu
- layer-shell (top/overlay/popup)
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.
The wlr_output_state passed to the new_output signal sometimes has a
non-preferred mode set, which we were ignoring before 03be489eb9.
Ignore it again to prevent the wrong mode from being set.
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.
output_config_apply() currently assumes that any enabled outputs have
already been added to the wlr_output_layout. However, at startup,
wlroots will report that outputs are enabled if they were previously in
use by e.g. the Linux console - but they are not yet in the layout.
output_config_apply() never encountered this case before now because the
initial modeset was performed by another code path, but now with the new
autoEnableOutputs option (next commit), it needs to be able to handle
the initial modeset as well.
If e.g. kanshi requests us to enable an output but does not specify the
mode, and the output has not previously been modeset, then the width +
height + refresh rate will all be zero. In this case, we should select
the best mode just as when auto-configuring a new output.
We need to do the mode auto-selection in both the test & commit stages
for consistency, so factor out a new output_test_auto() function to help
with this.
Remove a guard against a refresh rate of zero, which was a workaround
for wlroots 0.17 and is no longer needed -- it is incompatible with mode
auto-selection since the refresh rate is zero in that case.
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.
This commit cleans up the comments and cruft from e45fe08.
Background:
- With e45fe08, the keyboard focus is always moved to the switched window
on finishing window switcher, even with <focus followMouse="yes">.
Since followMouseRequiresMovement was not implemented at that time
(behaved like it was always "no"), e45fe08 was necessary to allow users
users who use followMouse="yes" to move the keyboard focus with window
switcher.
- 9a9e20d added followMouseRequiresMovement, but it kept the behavior
described above even with followMouse="yes" and
followMouseRequiresMovement="no".
- 398b80b accidentally invalidated e45fe08, which means the keyboard focus
is now always moved to the window below the cursor on finishing window
switcher with followMouse="yes" and followMouseRequiresMovement="no".
Although the invalidation was a accident, I think always setting the
keyboard focus on the window below the cursor is what users expect from
followMouse="yes" and followMouseRequiresMovement="no".
...to WLR_INFO to avoid logging issues with .desktop files as errors, for
example:
[sfdo-desktop] 1:1: Name is unset
[sfdo-desktop] Failed to load /usr/share/applications/lxqt-panel.desktop
[sfdo-desktop] 1:1: Exec is unset while DBusActivatable is unset or false
[sfdo-desktop] Failed to load /usr/share/applications/qemu.desktop
Also make libsfdo debug/info logging depend on environment variable
LABWC_DEBUG_LIBSFDO being set to avoid disproportionately verbose logging
by default for one particular sub-system.
Add an 'ENVIRONMENT VARIABLES' section to labwc(1) to describe the above
as well as other hitherto undocumented env vars with prefix LABWC_DEBUG_.
