| Summary: | Implement toggle for "Sticky corners", preventing mouse cursor moving between monitors in corners | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Ridge <kde> |
| Component: | multi-screen | Assignee: | fanzhuyifan |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | abdulalzeidi, fanzhuyifan, kde, kdebugs.81do7, kdebugs, me, miranda, natalie_clarius, nate, notmart |
| Priority: | NOR | Keywords: | usability |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=416570 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/ad13765348403122747b02e7c26539b55a624dd5 | Version Fixed In: | 6.1 (Wayland-only) |
| Sentry Crash Report: | |||
| Attachments: | An example image showing a mouse cursor moving into a corner, and its trajectory sliding onto the adjacent monitor. An example of a 25px threshold is also drawn on top | ||
Moving to KWin. Not sure about the component, but it's definitely closer. Can confirm. Lately I'm working on Windows machine as a primary desktop, and gotta admit: it has this nice feature of _sometimes_ magically stopping the cursor from moving to the other screen. Often it triggers unpredictably or when not needed at all, but that's just a matter of heuristics which can and should be improved. (In reply to ratijas from comment #1) >Moving to KWin. Not sure about the component, but it's definitely closer. Thanks a lot! >it has this nice feature of _sometimes_ magically stopping the cursor from moving to the other screen. Often it triggers unpredictably or when not needed at all, but that's just a matter of heuristics which can and should be improved. Glad I'm not alone 😁 I agree, it can and should definitely be improved upon and not carbon copied. I found that Windows stops your cursor completely in corners about... 2-ish percent of the screen up and downwards depending on the corner location. I think this is perfect, but it should be configurable. It also stops your mouse on **any** edge if you're dragging a window; UNLESS your cursor is traveling at a certain speed. This can be a blessing and a curse.. Again, also how it can be improved upon. I like the function, but wish I could tune the velocity threshold when I do have no option but to use Windows. Others will definitely want to disable it. *** Bug 474842 has been marked as a duplicate of this bug. *** I'll take a look at this after the MR about sticky edges gets sorted out. Git commit ad13765348403122747b02e7c26539b55a624dd5 by Yifan Zhu. Committed on 08/03/2024 at 20:03. Pushed by fanzhuyifan into branch 'master'. pointer_input: implement edge barrier between screens Allow users to configure a virtual edge barrier between screens. The pointer will only cross over to the other screen after the distance travelled surpasses edgeBarrier. Reduce the speed during interactive moveresize, at edges that trigger, and at the corner. Only supports wayland. Doesn't have X11 support since it is far too complicated there. Related: bug 416570 M +4 -0 autotests/integration/kwin_wayland_test.cpp M +89 -0 autotests/integration/pointer_input.cpp M +4 -0 autotests/integration/screens_test.cpp M +10 -0 src/kcms/screenedges/kwinscreenedgesettings.kcfg M +55 -0 src/kcms/screenedges/main.ui M +10 -0 src/kwin.kcfg M +22 -0 src/options.cpp M +30 -0 src/options.h M +83 -2 src/pointer_input.cpp M +15 -1 src/pointer_input.h M +10 -0 src/screenedge.cpp M +4 -0 src/screenedge.h https://invent.kde.org/plasma/kwin/-/commit/ad13765348403122747b02e7c26539b55a624dd5 Since this is very difficult to implement on X11, and given that kwin X11 is feature frozen and the default session type is now wayland, we won't be supporting this on X11. (In reply to fanzhuyifan from comment #7) Perfect, thank you SO very much! Can't wait to give this a try. I was about to file a bug because it was driving me nuts that I sometimes couldn't move my mouse across my screens. I'm not sure where the best place is to discuss the "default" behavior here. However, this seems to me like an off by default accessibility option not run of the mill default behavior. If Windows does this by default ... that's nice for Windows but as a long time Linux user this behavior was shocking and frustrating. (In reply to Wyatt Childers from comment #9) > I was about to file a bug because it was driving me nuts that I sometimes > couldn't move my mouse across my screens. > > I'm not sure where the best place is to discuss the "default" behavior here. > However, this seems to me like an off by default accessibility option not > run of the mill default behavior. If Windows does this by default ... that's > nice for Windows but as a long time Linux user this behavior was shocking > and frustrating. If it's about moving the mouse across edges, not shared corners, then you're looking for #416570 and not this ticket. (In reply to miranda from comment #10) > (In reply to Wyatt Childers from comment #9) > > I was about to file a bug because it was driving me nuts that I sometimes > > couldn't move my mouse across my screens. > > > > I'm not sure where the best place is to discuss the "default" behavior here. > > However, this seems to me like an off by default accessibility option not > > run of the mill default behavior. If Windows does this by default ... that's > > nice for Windows but as a long time Linux user this behavior was shocking > > and frustrating. > > If it's about moving the mouse across edges, not shared corners, then you're > looking for #416570 and not this ticket. Good to know... It's both really. The edges were the worst part but the corners were also getting me (two firefox windows maximized, you go to move over to the first tab on the screen to the right, and you're "blocked" by an invisible wall). I do really like the feature and appreciate that it has been implemented, though I can add my two cents to the conversation: I agree it shouldn't be on by default, and while corners can be "sticky" by default, edges are probably better to only be sticky if grabbing a window, since that's when they're most useful (for quick tiling). (In reply to Wyatt Childers from comment #11) > (In reply to miranda from comment #10) > > (In reply to Wyatt Childers from comment #9) > > > I was about to file a bug because it was driving me nuts that I sometimes > > > couldn't move my mouse across my screens. > > > > > > I'm not sure where the best place is to discuss the "default" behavior here. > > > However, this seems to me like an off by default accessibility option not > > > run of the mill default behavior. If Windows does this by default ... that's > > > nice for Windows but as a long time Linux user this behavior was shocking > > > and frustrating. > > > > If it's about moving the mouse across edges, not shared corners, then you're > > looking for #416570 and not this ticket. > > Good to know... It's both really. The edges were the worst part but the > corners were also getting me (two firefox windows maximized, you go to move > over to the first tab on the screen to the right, and you're "blocked" by an > invisible wall). While true, you'd probably have a more convincing position challenging the defaults in #416570. MacOS, Windows, Android etc all utilize infinite targets (Fitt's law) which this feature follows. The other ticket is very much not that and is a bit of an odd duck in terms of default behavior. (In reply to Ridge from comment #12) > I do really like the feature and appreciate that it has been implemented, > though I can add my two cents to the conversation: I agree it shouldn't be > on by default, and while corners can be "sticky" by default, edges are > probably better to only be sticky if grabbing a window, since that's when > they're most useful (for quick tiling). If you're okay with corners being sticky by default then the conversation should be redirected to #416570 (In reply to miranda from comment #14) > If you're okay with corners being sticky by default then the conversation > should be redirected to #416570 Sorry, and thank you! |
Created attachment 147636 [details] An example image showing a mouse cursor moving into a corner, and its trajectory sliding onto the adjacent monitor. An example of a 25px threshold is also drawn on top SUMMARY To aid with button interactions in monitor corners, the four corners of a monitor should (optionally) stop quick mouse movements towards corners from moving onto the adjacent monitor. HOW THIS IS USEFUL TO USERS An example for a user with the close button in the top left of an application: They quickly move their cursor to the top left, to close a maximized application. However due to the quick movement, the cursor slides onto the left-adjacent monitor. Plasma stopping the mouse cursor from doing this in corners would be a great quality-of-life improvement for users with many monitors, who tend to maximize applications on several monitors. This is only an example, there are more benefits to this. Another use case I can imagine this is extremely helpful for, is to aid hot corner usage for window tiling. Let me use a final, personal example: I have a hotkey bound to Spectacle rectangle selection, to copy a screenshot to clipboard quickly. Sometimes I want to capture screenshots beginning in a screen edge, with these "sticky" corners, worrying about capturing pieces of adjacent monitors (or manually editing these tiny details) is no longer needed. It would also be nice if this could have a configurable threshold. Let's say by default, on a 1080p monitor, it stops your mouse cursor if it tries to move to the other screen 20~25 pixels within the top or bottom of the screen. A slider can let users define this threshold themselves. The feature is most likely best for power users. So at your own discretion, would best be implemented as an optional feature, disabled by default to avoid confusion for existing Plasma users if anything. STEPS TO REPRODUCE 1. With a multi-monitor setup, move the mouse cursor all the way down or up into a corner that has another monitor next to it 2. Move the mouse cursor towards the other monitor OBSERVED RESULT The mouse cursor moves freely to the other monitor with no resistance EXPECTED RESULT Plasma should ideally stops the mouse cursor from moving onto the other monitor SOFTWARE/OS VERSIONS Linux: Linux 5.16 ("Zen") KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION An implementation of this feature can be observed in action with Windows 8 or newer. In case my explanation is not clear, I have attached an image which should hopefully clarify. Apologies if this is the wrong category to post this wish in. Thank you for reading!