Replies: 1 comment
-
|
have the exact same problem except I'm using river as my window manager. interesting thing is that I'm using a fork of both waybar and river which hasn't been updated since this started happening which implies that it was the wlroots update from my package manager that triggered the bug. this lines up with your case because both river and sway use wlroots |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I'm a quite passive user of sway (1.10.1) and waybar (0.12.0) on a Gentoo system and haven't changed my configuration for years. My waybar is on the bottom of the screen. Recently, (most likely after an update) I noticed a change in the mouse behavior and I'm not sure where to look for the culprit (is it sway, gtk, waybar, or something else?), so I try to get some feedback here.
Previously, I could just move my cursor over the workspace buttons or over the pulseaudio module and use the mouse wheel to change the workspace or the audio volume. It was really convenient because I could just move the cursor to the edge of the screen. That is great usability because I do not have to aim for the actual buttons and modules.
Now, it doesn't work like this anymore because the edge / lowest pixel of the screen does not seem to belong to the workspace buttons or pulseaudio module anymore. I checked it via ":hover" effects in the stylesheet. It is necessary, to move the cursor a pixel in upwards direction to have the hover effect and a working mouse wheel action.
I also tried using the default stylesheet, but it has the same behavior. Does anyone have an idea what I have to change to get the old behavior back? Help is greatly appreciated.
Thank you very much.
Beta Was this translation helpful? Give feedback.
All reactions