
Various KDE 1.-4. Improvements
Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net
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.
15 years ago
- 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
15 years ago
- 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
p0z3r
15 years ago
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'.
Report
pfeiffer
15 years ago
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.
Report
pfeiffer
15 years ago
"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')
Report