swaybar: prioritize workspace scroll over bindsyms #8299
Conversation
|
Note 1: Some people desire to disable scrolling to switch workspaces: #1041, #4114. It's unclear to me if they don't like it being triggered when scrolling over free bar space (if so, this change is OK for them) or with the entire concept in general (if so, this change will make them unhappy). Note 2: I realized that with #6482, while fixing i3 compatibility for tray icons, I broke it for workspaces: After it, a The underlying conceptual problem is that i3bar has three levels: Tray icons, bindsyms, then workspaces, in descending priority. In swaybar, we only have two: Hotspots (which include both tray icons and workspaces) and bindsyms. So, to make things consistent, we should either prioritize hotspots over bindsyms everywhere (this is what this PR does, at the cost of further breaking i3 compatibility), or be faithful to i3's behaviour (e.g. make workspaces "low-priority hotspots" or special-case them). |
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ó <[email protected]>
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 53f9dbd ("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ó <[email protected]>
joanbm
force-pushed
the
prioritize_workspace_scroll_over_bindsyms
branch
from
16004e5
to
9431d06
Compare
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:
After this commit:
If the user has no bindsyms for Button4/Button5, there is no change.
Utility
This shows an example of why this is useful. Here, the user has set up a Button4/Button5 bindsym to change the volume (see: top right corner) when scrolling over the bar.
Before this change, the user could no longer use the mouse wheel to switch workspaces:
After this change, the user can (only when scrolling over the workspaces):
Discussion
This is consistent with the idea that workspaces are hotspots, and hotspot event handlers take priority over the user's bindsyms, see 53f9dbd ("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.