This adds handling for scroll events (e.g. mouse wheel) to the hotspot
callback equivalent to the fallback in `process_discrete_scroll`.
While this may seem redundant (and in many cases, it is), it changes
the priority when the user has Button4/Button5 bindsyms on the bar.
Before this commit:
* Scrolling on unused bar space calls the user's bindsyms.
* Scrolling over the workspaces *still* calls the user's bindsyms.
After this commit:
* Scrolling on unused bar space calls the user's bindsyms.
* Scrolling over the workspaces moves to the previous/next workspace.
If the user has no bindsyms for Button4/Button5, there is no change.
This is consistent with the idea that workspaces are hotspots, and
hotspot event handlers take priority over the user's bindsyms, see
53f9dbd424 ("swaybar: Prioritize hotspot events to bar bindings").
However, note that this strays further away from i3's behaviour.
On i3, user bindsyms take precedence over workspaces, even for Button1.
In fact, it's explicitly documented as such:
https://web.archive.org/web/20240725173949/https://i3wm.org/docs/userguide.html#_mouse_button_commands
Signed-off-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
Move the workspace pointer/touch button handling logic from render.c
to input.c, and reorganize it so handling more buttons is more natural.
No functional change intended.
Signed-off-by: Joan Bruguera Micó <joanbrugueram@gmail.com>
Updating the cursor is not essential, so this change prints
a warning when wl_cursor_theme_load or wl_cursor_theme_get_cursor
fail instead of crashing or exiting.
When `wrap_scroll yes` is configured and there's only one workspace
open, swaybar will mark it as not visible if the user scrolls on it and
eventually incorrectly fail the `active->visible` assert.
Fix this by making sure that new and current workspace aren't the same.
The previous commit prioritized hotspots before bar bindings for press events,
which matches i3's behaviour. However, since hotspots don't need to do any
processing on release events, those were not handled, and simply fell through
to `bindsym --release` bar bindings (if any).
This is counter-intuitive, and doesn't match i3's behaviour. Instead in case
a hotspot handles the press event, it should also handle the release event,
doing nothing, but blocking the event from triggering a --release bar binding.
E.g., in Sway, without this commit, this config. shows a text on tray clicks:
bar {
# ...
bindsym --release button1 exec swaynag -m I_got_the_release_event.
}
But the same configuration in i3 (with i3-nagbar) doesn't show the text.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
This is consistent with i3bar's behaviour, and for example, allows binding a
command to button1, while still being able to click on tray icons or other
zones on the bar's status line which may have their own bindings.
E.g., in Sway, without this commit, this config. makes tray icons unclickable:
bar {
# ...
bindsym button1 exec swaynag -m You_clicked_the_tray._Want_some_help?
}
But the same configuration in i3 (with i3-nagbar) keeps tray items clickable.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Only wl_pointer.motion was used to update pointer position, which would
cause issues if the pointer was not moved prior to wl_pointer.button.
This also fixes touch input through wl_pointer emulation, which fires
wl_pointer.button immediately after wl_pointer.enter.
Copied from a similar fix made to swaynag.
Closes: https://github.com/swaywm/sway/issues/6109
24e8ba048a did not take scaling into account.
The hotspot size used pixel coordinates, the absolute coordinates were logical,
and the relative coordinates were completely wrong.
This commit makes all coordinates use logical values. If
`"float_event_coords":true` is sent in the handshake message, coordinates are
sent as floating-point values.
The "scale" field is an integer containing the scale value.
Note: since strtoul() has no real error return code (both 0 and
ULONG_MAX may be returned on both success and failure), set errno=0
before calling strtoul().
If the XCURSOR_THEME and/or XCURSOR_SIZE environment variables are
set, use the theme and size they define.
If they're not set, use the same defaults as before (system default
theme, size=24).
This commit mostly duplicates the wlr_log functions, although
with a sway_* prefix. (This is very similar to PR #2009.)
However, the logging function no longer needs to be replaceable,
so sway_log_init's second argument is used to set the exit
callback for sway_abort.
wlr_log_init is still invoked in sway/main.c
This commit makes it easier to remove the wlroots dependency for
the helper programs swaymsg, swaybg, swaybar, and swaynag.
This modifies `bar_cmd_tray_bindsym` to use `get_mouse_bindsym` for
parsing mouse buttons. This also introduces `bar_cmd_tray_bindcode`,
which will use `get_mouse_bindcode` for parsing mouse buttons. Like with
sway bindings, the two commands are encapsulated in a single file to
maximize shared code.
This also modifies tray bindings to work off of events codes rather than
x11 buttons, which allows for any mouse buttons to be used.
For `get_bar_config`, `event_code` has been added to the `tray_bindings`
section and will include to event code for the button. If the event code
can be mapped to a x11 button, `input_code` will still be the x11 button
number. Otherwise, `input_code` will be `0`.
This modifies `bar_cmd_bindsym` to use `get_mouse_bindsym` for parsing
mouse buttons. This also introduces `cmd_bar_bindcode`, which will use
`get_mouse_bindcode` for parsing mouse buttons. Like sway bindings, the
two commands are encapsulated in a single file with shared code.
This also modifies swaybar to operate off of event codes rather than x11
button numbers, which allows for any mouse button to be used.
This introduces two new IPC properties:
- For `get_bar_config`, `event_code` has been added to the `bindings`
section and will include to event code for the button. If the event code
can be mapped to a x11 button, `input_code` will still be the x11 button
number. Otherwise, `input_code` will be `0`.
- Likewise for `click_events`, `event` has been added and will include
the event code for the button clicked. If the event code can be mapped
to a x11 button, `button` will still be the x11 button number.
Otherwise, `button` will be `0`.
evdev-proto is installed by a dependency, so some files have been missed:
In file included from ../sway/input/cursor.c:3:
/usr/local/include/libevdev-1.0/libevdev/libevdev.h:30:10: fatal error: 'linux/input.h' file not found
#include <linux/input.h>
^~~~~~~~~~~~~~~
../swaybar/i3bar.c:3:10: fatal error: 'linux/input-event-codes.h' file not found
#include <linux/input-event-codes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
This fixes a few issues with swaybar's cursor scaling:
1. The cursor scale is now changed when the output scale changes
2. The cursor scale is no longer bound by the max output scale when
swaybar is launched
3. Related to the previous item, the cursor is no longer tiny on low
scale outputs after the max output scale has changed
This also bumps up `wl_compositor` to version 4 to allow usage of
`wl_surface_damage_buffer`.
