Version: unknown (using KDE 3.4.2, Debian Package 4:3.4.2-4 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.12-1-k7 I would like that when I open a dialog window (like Help->About ) the mouse cursor to jump to the default button. A control center option is needed to set this behavior on/off.
snap-to mouse is bad for many reasons: it takes control of the mouse away from the user, user may 'lose' mouse position because they didn't move it themselves, it is especially bad in mouse-focus environment, etc... software accessibility makes the default button already available when the window is in focus. the system should never take control of the mouse away from the user. snap-to mouse would make interaction in a mouse-focus environment very annoying. unsolicited popups could steal focus and disrupt tasks. mouse cursors which 'hide' when user is typing could be lost. there is no benefit to snapping the mouse to a default button.
On Saturday 22 October 2005 22:47, Celeste Paul wrote: > snap-to mouse is bad for many reasons: > it takes control of the mouse away from the user it just moves the mouse > user may 'lose' mouse position because they didn't move it themselves it is moved to the default button, according to the SELECTED option in the control center > it is especially bad in mouse-focus environment, etc... why? > software accessibility makes the default button already available when the window is in focus. it is not avaible by just clicking(i realy like it) > the system should never take control of the mouse away from the user. The user sets this option(defaultshould be off) > snap-to mouse would make interaction in a mouse-focus environment very annoying. I like it :) > unsolicited popups could steal focus and disrupt tasks. I want this! > mouse cursors which 'hide' when user is typing could be lost. When the mouse is moved to the default button it should be set ON(not hidden) > there is no benefit to snapping the mouse to a default button. Most dialog windows are just simple questions and the default answer is ,usually, the correct one.
Note: This feature is part of Firefox/IE/Mozilla/Opera and I'm told Safari as well. It is also worth noting that this is a feature recommended by design experts such as Jeff Raskin (Yes I know he's dead but he wasn't when he was talking about this.) and others.
Are you quite so sure? You've listed some browsers, but we're talking about the whole desktop. Besides, our usability experts say we shouldn't, so we'll do as they say.
> Note: This feature is part of Firefox/IE/Mozilla/Opera it is? i just checked Safari, FF, and IE and none of them mouse snap-to a button on accessing the help->about window, an error, or a popup. it would be silly for a single application to have different behavior than the rest of the environment. afaik in mac osx there is no such thing as mouse snap-to button focus without the aid of a plugin or addon. > is a feature recommended by design experts such as Jeff Raskin what paper/book are you referencing? i seem to remember raskin stating the complete opposite in "the humane interface". you should NEVER take the control of or change focus of an input device such as keyboard or mouse. this includes moving the mouse to focus on a button upon an event.
being OFF by default it should hurt ONLY the people who enable it. I'm sure that the people who enable it , will know what they are doing. The reason why i need this option is that I'm a lazy person, so I'm tired of (always) moving the mouse to respond to a dialog window(especially those with Yes/No buttons or Continue/Stop buttons): moving the mouse to the default button will make easier to click even the non-default buttons(because all buttons are close together)
You can add that the cursor rego to its place before the popup
Created attachment 13118 [details] dialog windows images where mouse move will help(tar arhive)
I will REOPEN the bug(wish). Some kde USERS (not "experts", just people that use kde every day) asked me on KDE IMPROVEMENTS where they can "download" this: by dionis on: 10/23/2005, 14:54 where have i to click to get the download? Others agreed that this is a good option: by AlexeyK on: 10/23/2005, 12:36 I think I never will use this feature, but i voted for this because there must as much features in KDE as possible [on my look] I also noticed this comment: by DIHLOFOS on: 10/23/2005, 21:12 KDE is about features and customizability. Just give me this feature and leave it to me whether I'm going to use it or not. If you wish to get a preconfigured and hard to customize desktop get yourself a Gnome. Celeste should read the next comment: by DIHLOFOS on: 10/23/2005, 21:38 Big this project up guys. Its not all about the experts and they have to respect what the users want. This wish should stay open until GOOD arguments are written against it or ... implementation!
bugs.kde.org rule: do not reopen WONTFIX bugs unless you want to implement this feature yourself. Therefore, I am reassigning this to zvonSully.
*** This bug has been confirmed by popular vote. ***
http://kde-look.org/content/show.php?content=30523 35% isnt a very good rating.. .. and you missed these comments in your reposting (#9): jpesto: ...It is a sign for good software if it rejects the proposals that don't bring a good usefullness vs. complexity ratio with them. As you can clearly see at the good/bad percentage, this one is such a feature, most people think similar as I do, and I love KDE for being consequent enough to not integrate every possible feature that you could think of. bennevis: I don't like this at all! Back in my Windows days I used a logitec driver with this feature and it was so annoying! It produced false (as in unwanted) clicks all the time, because it makes you click on stuff my accident.
On comment #10 : >bugs.kde.org rule: do not reopen WONTFIX bugs unless you want to implement this feature yourself. Therefore, I am reassigning this to zvonSully. I reopened the bug because "I had new info". I don't know qt libs to hack them, but I write here the algorithm: I supose that the parent of the buttons(the window) sends an message to the buttons at activation. Next I will write the handler function for that event( I think that events are called signals in qt ?! ) void TButton::Activate() { if( this->IsDefault() && Options->MvMouse2DefButton(true))//check if this is the default button and if the option is on { Mouse->DisableClicking(Options->GetClickDisTime());//disable clicking for 300 ms : enought not to make "accidental clicks" Mouse->Move2(ToGlobal(this->Center));//moving mouse to the CEnter of the button } } Note: Mouse->DisableClicking(time); time is configured in kcontrol; default 0 Is this algorithm ok?
btw : rating for this wish at KDE Improvements http://kde-look.org/content/show.php?content=30523 has increased to 42 % . So many USERS(not the developers) want this option.
*** Bug 80678 has been marked as a duplicate of this bug. ***
bug 80678 : The end result should be that people can click on buttons and links and so on faster and more accurately, and it should make life easier for people with disabilities. What about this Celeste ?
Note to potential implementors: please disregard the vote count, it's skewed by external linking.
4 years since my report, I changed my mind: I don't like my mouse to jump to the default button. Maybe someone should make an option for those who want this behavior...