| Summary: | Option for "sticky edges" in multi-screen configuration | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Akshay Naik <naik.akay> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | 123123213ewrewq, ashark, boslmari7, fanzhuyifan, kde, l.allulli, lenz.koxholt, manuelchaves, miranda, natalie_clarius, nate, plasma-bugs, prettyvanilla, xaver.hugl, zini.fin+kde |
| Priority: | NOR | ||
| Version: | 5.17.5 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | All | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=451744 https://bugs.kde.org/show_bug.cgi?id=478068 |
||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/ad13765348403122747b02e7c26539b55a624dd5 | Version Fixed In: | 6.1 (Wayland-only) |
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 351175 | ||
|
Description
Akshay Naik
2020-01-22 11:18:48 UTC
*** Bug 416571 has been marked as a duplicate of this bug. *** > OBSERVED RESULT
> Notice that it is easy to unintentionally move the cursor to the other screen.
Can you describe why this is a problem? You can just move the cursor back, right? Is moving the cursor a problem?
(In reply to Nate Graham from comment #2) > Can you describe why this is a problem? You can just move the cursor back, > right? Is moving the cursor a problem? Consider the following common cursor based actions on a window displayed in the left-side screen of a dual-monitor setup: 1. Closing/minimizing etc. a window using the right-most button on the titlebar. 2. Quickly moving the cursor to the right to click/drag the scrollbar. Users typically rely on quickly moving the cursor all the way to the right to correctly place it over the required UI element without actually following the cursor with their eyes(which would allow fine motor control-and also distract from the task at hand). Not having a soft barrier between screens thus negatively affects user experience. Windows does something similar but I believe only in certain areas, e.g. when moving the cursor between screens at the top edge of the screen to accomodate for hitting the window close button of maximized windows. Otherwise it would be wildly annoying every time I want to move between screens to have some pressure to overcome. Thanks for the info. (In reply to Kai Uwe Broulik from comment #4) > Otherwise it would be wildly annoying every time I want to move between > screens to have some pressure to overcome. Perhaps you're right about this. I'm new to a multi-screen setup and haven't truly used it fully. > Windows does something similar but I believe only in certain areas, e.g. > when moving the cursor between screens at the top edge of the screen to > accomodate for hitting the window close button of maximized windows. This might be the better solution. Top-only(pre-defined) or user-defined regions of pressure. Has there been any update on this feature? I think it would be highly useful now that multi monitor setups are becoming more widespread and it doesn't seem to be something too hard to implement. (In reply to Akshay Naik from comment #6) > This might be the better solution. Top-only(pre-defined) or user-defined > regions of pressure. I think user-defined regions of pressure should be the way to go. Sure, pressure on the upper right and lower right edges of the screen are usually useful to hit the usual locations of the "Show Desktop" button and the button to close a window easily without moving the cursor to the second monitor, but you should also consider the scrollbars. It's really annoying and time consuming to have to carefully point the cursor at the (usually) narrow scrollbars of many applications, such as web browsers. If a user doesn't like this feature, maybe a toggle to turn it off could be implemented as well. I wanted to report this for a long time! It really annoys that you need to be very precise near edges, or your mouse could be accidentally appear in the next monitor. I did not know that it is called "sticky edges" in some desktop environments, sounds confusing, it does not "stick" actually. Probably we should name it "edge obstacle - stops the mouse/window movement at crossing screen edges if the move vector is lower than threshold." This thing is implemented in openbox (as well as in windows os). You can try it like this: ``` Xephyr -br -ac -noreset -screen 800x600 :2 -resizeable -host-cursor & # not sure about all options though, but it works ok DISPLAY=:2 openbox & ``` Then in the xephyr window, right click, select Terminals, xterm. And try to move that xterm window through the end of xephyr's window. You will see that edges are obstacle a bit. Then if you are insisting, moving mouse further (speed actually does not matter), then it is passed. *** Bug 421254 has been marked as a duplicate of this bug. *** (In reply to Kai Uwe Broulik from comment #4) > Windows does something similar but I believe only in certain areas, e.g. > when moving the cursor between screens at the top edge of the screen to > accomodate for hitting the window close button of maximized windows. In Windows while dragging a window there are also sticky edges. Therefore you can easily snap windows on the edge without even looking. This feature can also be seen from an accessibility point of view as people with disabilities may find it difficult to aim for the edge of the screen. Or they might find it impossible to use multiple hands thereby making it impractical to use persisting KWin Scripts that add keyboard shortcuts for window snapping. As I would imagine it there should be a feature called 'Screen Barrier' or smth where you can specify multiple behaviours while dragging a window or just moving your mouse across screen edges. You can specify this to only be the case for corners or the whole edge basically giving a slider how much of a percentage your screen edges should be obstructed. There should also be a force option where you can specify a threshold after which your cursor overcomes the barrier. This way you can have corners that you can quickly drag your mouse to to access certain UI elements and at the same time have edges where you can easily snap windows to by dragging them to the edge. An important addition that I wanted to say long time ago : In KDE the sticky window edges is already implemented. I mean they are really "magnet moved" a bit when you drag it near the edge. And it feels like a tiny obstacle (this is nice). It is however not configurable. The problem is when mouse is moved when not in window dragging mode. And also, even in window dragging mode, the "edge obstacle" is missing when a _mouse_ (not window edge) goes through the screen edge (when you want to tile a window on one screen before reaching the next monitor). To make it more understandable, I recorded a demo: https://youtu.be/TgFmuO0R4A8 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5166 Reading this, there's two different issues at play and I feel like some of the discussion is overlapping. There's "sticky edges", which are great for facilitating snapping windows and highlighting scrollbars. But "sticky corners" are a completely separate concept, and help with corner buttons like closing windows and opening the launcher. The latter is reported in #451744, and relies on "Fitt's law": http://particletree.com/features/visualizing-fittss-law/ Users with single monitors become used to quickly slamming their mouse into a corner to reach an action. It's part of why MacOS has kept that fixed menu bar at the top of the screen (as much as its use has been de-emphasized in recent years). And relevant to this discussion, multi-monitor setups can break this functionality. Fixing that involves stopping the mouse entirely on shared corners, not just adding "pressure". A small magnetic effect still doesn't accommodate Fitt's law (ie an infinitely large target). Microsoft solved this problem back in 2012, and they described their thought process here: https://web.archive.org/web/20160701204429/https://blogs.msdn.microsoft.com/b8/2012/05/21/enhancing-windows-8-for-multiple-monitors/ My point is, I *really* don't think we should to rely on this feature (don't get me wrong, it's a great idea!) for shared corners, only shared edges. I would love if the conversation for corners was redirected to #451744. (In reply to miranda from comment #14) > My point is, I *really* don't think we should to rely on this feature (don't > get me wrong, it's a great idea!) for shared corners, only shared edges. I > would love if the conversation for corners was redirected to #451744. Yes, definitely. The current proposed MR implements a very "soft" barrier, so that it would not obstruct normal movement across screens. For the corners we definitely should implement a harder barrier. 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 451744 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. *** Bug 427873 has been marked as a duplicate of this bug. *** |