Okay, so this is an interesting one. So I updated to Fedora 31 a short while ago (upgrading to Gnome 3.34.1), which broke Slinger due to #24, but when I tried using the fixed version, I noticed some very weird behaviour.
Basically, the "disc" which opens when Win-A is pressed, does not open under the cursor when the application you're hovering over is using Wayland - it seems to choose a semi-arbitrary position on the screen. I've seen it happen right in the middle of the screen, somewhere over the current application, or on an empty spot on the desktop. Moving the window, alt-tabbing, resizing, launching applications, or switching workspaces does not deterministically cause a change in position. Nor does it matter which window is focused.
However, it does work normally when the application you're hovering over is using XWayland! Even more interesting, when you've hovered over an XWayland application, the last position of your mouse over a visible portion of that window becomes the new location the disc will open at.
So it seems that whatever API is being used to get the mouse position works fine with XWayland, but breaks with pure Wayland. There are no errors in the log, though. To add to the mystery, once the disc is open, moving the mouse around to choose a section works properly, even when moving over non-Wayland windows. Clicking for selection works as well.
Okay, so this is an interesting one. So I updated to Fedora 31 a short while ago (upgrading to Gnome 3.34.1), which broke Slinger due to #24, but when I tried using the fixed version, I noticed some very weird behaviour.
Basically, the "disc" which opens when Win-A is pressed, does not open under the cursor when the application you're hovering over is using Wayland - it seems to choose a semi-arbitrary position on the screen. I've seen it happen right in the middle of the screen, somewhere over the current application, or on an empty spot on the desktop. Moving the window, alt-tabbing, resizing, launching applications, or switching workspaces does not deterministically cause a change in position. Nor does it matter which window is focused.
However, it does work normally when the application you're hovering over is using XWayland! Even more interesting, when you've hovered over an XWayland application, the last position of your mouse over a visible portion of that window becomes the new location the disc will open at.
So it seems that whatever API is being used to get the mouse position works fine with XWayland, but breaks with pure Wayland. There are no errors in the log, though. To add to the mystery, once the disc is open, moving the mouse around to choose a section works properly, even when moving over non-Wayland windows. Clicking for selection works as well.