Corner Mouse Traps

Bug #990902 reported by ijk on 2012-04-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design

Bug Description

Putting your mouse cursor into a corner on a single head system is easy to do fast, because the edge of the screen guides the pointer and is therefore highly usable.

These properties could be exploited in parts of the screen that aren't actually corners, by implementing virtual barriers to the mouse pointer. I suggest such barriers in corners with adjacent monitors (so the system menu on the top right of a left hand screen of a side-by-side dualhead setup).

Also they could be on the top and right edges of the Dash home button - so you can slam the cursor into the top corner, deliberately aiming slightly left and hit the dash home button every time instead of the close button.

This could be abstracted further for a launcher button on the bottom right of a 4 monitor 2x2 setup by making the edges that the cursor didn't cross to get into the launcher button, virtual barriers - A rotating C shape on top of the launcher button that catches the cursor. This would also work for edge cases where there it's possible to move the cursor off the screen because not all of the desktop area is covered by monitors - eg a dualhead 'T' setup

This would also be useful for the bottom right corner - even though it's not used by unity it would become a valuable space in programs on multi-montior setups where it's not a 'physical' corner. eg for a firefox extension button. It shouldn't affect a cursor in the act of moving windows. Alternatively the bottom right corner could launch the compiz expose type function by default.

When you slam a cursor into a corner it can take a moment for you to register where it actually went. Because of this the capturing icon should show instant visual feedback that it contains the walled in cursor - the obvious mechanisim is a visual effect that's proportional to how much mouse distance the virtual wall has absorbed. Opening the indicator menu would be an obvious thing for the system menu to do if it's 'slammed'.

This could be abstracted even further to windowed windows - from below and to the right you throw the mouse cursor into the top left of your window (possibly guided by more virtual barriers) and you get a clickable batman type projection of the red X circle under the mouse cursor - and if you move the mouse further anticlockwise (relative to the close button) you get projections of the minimise and maximize buttons. At this point your mouse is quite a distance from that top left window corner it needed to enter so you don't need to be precise (sorry) with your mouse movements as the clickable projections are BIG. If that wasn't clear the effect would be similar to having a pie chart appear when you hit the top left of the window but with only 3 equal pie slices totaling a quarter pie extending some way (say 5" on a 22" screen).

ijk (ijk) wrote :

A batman/pie thing for multitouch would be where either you have one touch inside the window and another outside (of course you then have the full 360 to play with), or having a first touch (or long touch) on the home button and a second somewhere else (inevitably to the bottom and right somewhere) before the first touch is released. This would be a big improvement on the tiny close button. Even including a bigger version of the close/window/minimize for the current program when the home button is pressed (made visually intuitive) would be very helpful.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers