Implement "Catch-Areas" for Hot Corners When in a Multi-monitor Setup

Registered by phillip stuerzl

In a multi-monitor setup, currently, it can be rather difficult to activate hotcorners that lie at the middle of the two screens, ie- on the right side of the left monitor in a two-monitor setup, etcetera, as the mouse will just move on to the other monitor, and it can be difficult at times to quickly activate the hotcorner in comparison to a single monitor or one of the monitor corners that doesn't border another monitor. The current situation either leaves the use fumbling for a function that should be quick and easily, physically enacted, or forces the user to limit or altogether give up the use of hotcorners. (Not something I think is a positive experience, or something we should encourage.)

Other OSs and desktop environments, namely Windows 8/8.1 (I know, I know, but they do occasionally get something right.), solve this by providing small "catch areas" in those specifc hotcorners that block the mouse from going to the other monitor, essentially creating an artificially larger corner that can be easily and instinctually used, much more like its normal counterparts on the other side.
These catch-areas are relatively small pixel values/percentages of the screen, but make a big difference. (I'm not sure of the exact numerical implementation.) Testing could be done to find the optimum values that allow hotcorner use without being a detriment to other multi-monitor mouse movement.

(Sorry for the long, likely-mildly rambling/wordy writeup, but I wanted to provide a clear view of the issue, along with trying to impress how crucial this problem is to conducive usability and user workflows for those that do have multi-monitor setups.
 I personally, am willing to throw money at this to get it fixed, on bountysource, and I feel there are likely many others who would look forward to seeing this fixed/implemented, too.)

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
phillip stuerzl
Direction:
Needs approval
Assignee:
None
Definition:
Pending Approval
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.