Bug 416570 - Option for "sticky edges" in multi-screen configuration
Summary: Option for "sticky edges" in multi-screen configuration
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.17.5
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 416571 421254 427873 (view as bug list)
Depends on:
Blocks: 351175
  Show dependency treegraph
 
Reported: 2020-01-22 11:18 UTC by Akshay Naik
Modified: 2024-04-25 13:49 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1 (Wayland-only)
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Akshay Naik 2020-01-22 11:18:48 UTC
SUMMARY
It's a good idea to have sticky edges on a multi-monitor setup as provided by Unity. i.e. A user might want to be able to set up a pressure threshold which prevents the mouse from moving between screens inadvertently in certain situations. For example, one might want to have sticky edge during normal usage to keep the cursor on the screen of interest, but not want it while dragging a window between the screens.

STEPS TO REPRODUCE
Move mouse cursor across shared border between two screens on a multi-screen setup.

OBSERVED RESULT
Notice that it is easy to unintentionally move the cursor to the other screen. 

EXPECTED RESULT
A user might want to be able to set up a pressure threshold which prevents the mouse from moving between screens inadvertently in certain situations.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Other users expressing interest for such a feature:
1. https://askubuntu.com/questions/1056190/when-using-multiple-monitors-in-kubuntu-can-i-make-it-more-difficult-for-the-mo
2. https://askubuntu.com/questions/940496/where-is-the-sticky-edges-option-for-multiple-screens
3. https://www.reddit.com/r/kde/comments/8zbowi/disable_sticky_edges_on_multimonitor/
Comment 1 Akshay Naik 2020-01-22 11:25:21 UTC
*** Bug 416571 has been marked as a duplicate of this bug. ***
Comment 2 Nate Graham 2020-01-22 22:14:01 UTC
> 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?
Comment 3 Akshay Naik 2020-01-23 07:31:14 UTC
(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.
Comment 4 Kai Uwe Broulik 2020-01-23 07:53:41 UTC
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.
Comment 5 Nate Graham 2020-01-23 16:04:34 UTC
Thanks for the info.
Comment 6 Akshay Naik 2020-01-23 17:02:42 UTC
(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.
Comment 7 reso_magna 2021-11-10 03:46:30 UTC
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.
Comment 8 Andrew Shark 2021-11-14 17:18:18 UTC
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.
Comment 9 Zamundaaa 2022-08-23 09:47:35 UTC
*** Bug 421254 has been marked as a duplicate of this bug. ***
Comment 10 Lenz Koxholt 2022-10-21 16:45:02 UTC
(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.
Comment 11 Andrew Shark 2022-11-17 17:38:29 UTC
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).
Comment 12 Andrew Shark 2022-11-17 18:29:46 UTC
To make it more understandable, I recorded a demo: https://youtu.be/TgFmuO0R4A8
Comment 13 Bug Janitor Service 2024-02-10 23:46:53 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5166
Comment 14 miranda 2024-02-19 02:15:13 UTC
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.
Comment 15 fanzhuyifan 2024-02-19 03:31:16 UTC
(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.
Comment 16 fanzhuyifan 2024-03-08 20:54:31 UTC
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
Comment 17 fanzhuyifan 2024-03-08 20:56:40 UTC
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.
Comment 18 Zamundaaa 2024-04-25 13:49:45 UTC
*** Bug 427873 has been marked as a duplicate of this bug. ***