Description: I'd like to get feedback on a Qt patch that tries to make navigation in menus faster and easier by affecting the mouse movement in popups in various ways, such as automatically positioning the cursor. In such case it is necessary only to move up and down in the menus and click, no horizontal movement is necessary.
All the changes can be selectively turned on and off.
See http://home.kde.org/~seli/confine/ for details, the patch, and RPM packages for SUSE.
If you have a comment, feel free to add it below. If you just like the feature, please add your good vote (the same way, if you don't like it, vote against).
Thanks.Last changelog:
- Mouse is no longer forced to be restricted to the popup area (optional) - Middle and right click close popup - More aspects being configurable - Fixed various bugs like press->select->release mode not working properly or menu entries sometimes being accidentally selected
For anyone interested in viewing a previous discussion on this topic, I think this is the same thing, you can view it in the KDE mailing list archives.
http://lists.kde.org/?t=111633395900001&r=1&w=2
The one thing I saw that this is _good_ for, is accessibility. Otherwise, it takes away a users ability to have "free reign" over the desktop with his/her mouse. Changing that behavior, by default, probably isn't a 'Good Thing'.
Great! "movemouse" should become a default setting in KDE. If you've never suffered through watching someone laboriously move the cursor over to the right into a second or third submenu (esp. when the entries are too long) then you don't know what pain and suffering are and you won't notice when the "mouvemouse" option DoesWhatIMean. In other words, there is no restriction of cursor movement, only a very subtle and greatly helpful improvement to one of the oldest and worst problems with drop-down menus.
I personally may end up opting for the combination "movemouse" and "noautoopen" and possibly "nocursor" but not for "restrict", which I find too... "restrictive". But having these as user-configurable options is very nice and very KDE-like.
following up...
"nocursor" was very uncomfortable for me. If I am using keyboard shortcuts to navigate the menu then I expect this, but an "invisible cursor" (if I am moving the mouse then there must be something attached, right?) was too strange. Yes, once one remembers the mouse button commands for dealing with this there is no problem, and perhaps later I might want to add it, but I doubt it.
With "restrict" I think it should also automatically provide "noautooption". Without that I was too easily getting trapped,especially in one bad situation where a submenu is four levels down in submenus that open right, then left, then right (a document navigation menu).
Right now:
movemouse, noautoopen, (maybe 'accel')
Ratings & Comments
3 Comments
For anyone interested in viewing a previous discussion on this topic, I think this is the same thing, you can view it in the KDE mailing list archives. http://lists.kde.org/?t=111633395900001&r=1&w=2 The one thing I saw that this is _good_ for, is accessibility. Otherwise, it takes away a users ability to have "free reign" over the desktop with his/her mouse. Changing that behavior, by default, probably isn't a 'Good Thing'.
Great! "movemouse" should become a default setting in KDE. If you've never suffered through watching someone laboriously move the cursor over to the right into a second or third submenu (esp. when the entries are too long) then you don't know what pain and suffering are and you won't notice when the "mouvemouse" option DoesWhatIMean. In other words, there is no restriction of cursor movement, only a very subtle and greatly helpful improvement to one of the oldest and worst problems with drop-down menus. I personally may end up opting for the combination "movemouse" and "noautoopen" and possibly "nocursor" but not for "restrict", which I find too... "restrictive". But having these as user-configurable options is very nice and very KDE-like.
following up... "nocursor" was very uncomfortable for me. If I am using keyboard shortcuts to navigate the menu then I expect this, but an "invisible cursor" (if I am moving the mouse then there must be something attached, right?) was too strange. Yes, once one remembers the mouse button commands for dealing with this there is no problem, and perhaps later I might want to add it, but I doubt it. With "restrict" I think it should also automatically provide "noautooption". Without that I was too easily getting trapped,especially in one bad situation where a submenu is four levels down in submenus that open right, then left, then right (a document navigation menu). Right now: movemouse, noautoopen, (maybe 'accel')