[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: RFC: Restricting mouse in popup menus
From:       "Diego Moya \(a.k.a. TuringTest\)" <turingt () gmail ! com>
Date:       2005-05-19 13:49:35
Message-ID: 11ee04940505190649491a6733 () mail ! gmail ! com
[Download RAW message or body]

On 19/05/05, Diego Moya (a.k.a. TuringTest) <turingt@gmail.com> wrote:
> On 19/05/05, Lubos Lunak <l.lunak@suse.cz> wrote:
> > not to help developing RSI. Just try navigating e.g. in the K-Menu for a
> > while with the mouse button pressed, and you'll see what I mean (well, at
> > least now my hand hurts a bit). Also, it's also simply not technically
> > possible - if the mouse button has to be pressed, how will one click in order
> > to open the submenus? Otherwise the advantage is lost.
> 
> Agreed that my "quasimode" proposal would be best for small context
> menus, and maybe not so good for the bigger application main menus or
> the K-Menu.
> 

So my conclusion is this: a 'not bad' solution for your would be this:

- if you click-release on a menu, it will behave as usual.
- if you click-drag over the menu, the special
hidden-cursor-restricted-area mode will begin.
- if the mouse button is released, the highlighted action is selected
(or the menu is cancelled if the empty area is selected).

For submenus, you could either 
- open them as soon as they're selected, move to them if the second
button is clicked (without releasing the first one). This is called
"chording" ( http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=156
)
- if the mouse button is released when the submenu is highlighted,
open the submenu, unhide the cursor and return to the usual
non-restricted mode.
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]