Bug 193991

Summary: Mouse input single / double click should be changed to: safe action, quick confirm, and long confirm
Product: [Applications] systemsettings Reporter: Aaron Peterson <alpeterson>
Component: kcm_mouseAssignee: Marie Loise Nolden <nolden>
Status: RESOLVED INTENTIONAL    
Severity: wishlist CC: groszdanielpub, nate
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Unspecified   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Aaron Peterson 2009-05-25 07:51:45 UTC
Version:            (using KDE 4.2.85)
Installed from:    Ubuntu Packages

Mixing Double and single clicks can be confusing for users.


 We need to examine the actual purpose of the distinction, and be aware of physical limitations and accessibility needs of our users. 

Double clicks are used by default on windows for actions that need a quick sanity check, like "I am not a cat, yes I want to open this file" Another safety feature of mice, is that a double click is not registered when the mouse is moving, and sometimes single clicks are not registered when moving.


 Basically, where an application requests a double click now, we change the code to require the "quick confirm action required" action, which could be a single click for those who prefer that, or unable to double click, or a specific key or phrase being typed into the computer to confirm the action needs to occur. 

Where actions take single clicks to trigger actions, the "safe action triggers" option could be selected.

This selection of what confirmation is required could be configured in each  application, and remain consistent with other parts of the system by using the same actions.  (each application could of course have custom levels too to override the system default, and some would remain hard coded to accept single clicks) 

 These options would be presented in it's own system settings tab under input.

 It would be called "actions" options would include: quick action

safe action  default would be  single click ( with small movement )
quick confirm defaults to  double click (with small movement)
long confirm defaults to  single click with dialog (btw, implementation detail keyboard focus needs to be on cancel!)


Each action/confirm combo could be configured to be exactly the same! this is for people who have great coordination and have to do tasks repeatedly / and or mistakes are cheaper than dirt

here are the options for each action:
 how many clicks " " in how much time" 
 button depression time 
 how much movement (select units, percent of screen, pixels, inches, cm) 
 gesture
 keys pressed simultaneously (link to the keyshorcuts, select the one that needs to be on)
 dialog
  require password?
  delay before key activation hasten The same options are available for the other types of actions. 
  use quick confirm or quick confirm? (must avoid endless loop)
 script

Many of these options would not be visible in the system settings tab. They would be tucked into advanced and or be editable in the configuration file. 

Applications that need to use this are: 
1. kdownloader -- when I download a file, I want to be able to tell it that it needs at least long confirm to run the file on my system, I want it to take a double click and a dialog "are you sure?" (not really, I really just want quick confirm, but the "are you sure" is what windows does" There is no way that I want it to be a quick confirm... ;)

 2. Konqueror -- just to download a file, I want a long confirm...  also closing a tab is a quick confirm, closing a window with multiple tabs could be a quick confirm or a long confirm depending on preference

 3. Dolphin -- I desperately require opening files to be a quick confirm, and selecting items to be a safe action.

 4. System Settings -- I desperately need the system settings browser to be a safe action, because it behaves like a browser, and doesn't do harm by just browsing. (right now it's tied in with the single/double click action, and it's aggravating) 

5. There are more where this distinction is useful. Thank you

See also:
103007
40563
Comment 1 Aaron Peterson 2009-05-25 09:18:53 UTC
*** Bug 193982 has been marked as a duplicate of this bug. ***
Comment 2 Grósz Dániel 2009-05-25 12:53:32 UTC
As far as I know on Windows double clicks are used not as a confirmation but where single click has an other action (such as selecting the icon). Where there is no such action, it uses single click (e. g. for web links where opening something from a web page or sending a form is comparable to opening a file from the file manager). As when Windows uses double click the single click action is practically never needed, I think the current KDE defaults of using single click everywhere are right.
Comment 3 Aaron Peterson 2010-07-25 15:25:50 UTC
>As far as I know on Windows double clicks are used not as a confirmation but
where single click has an other action (such as selecting the icon). Where


I think there is room for us to both be correct, It serves as a sanity check, and it allows single click to do other things.

I believe I have another bug open requesting double click on icons as default, and I think that is a political battle that I can't win directly.



This generalization is more intended as a way to extend into new input devices.

For example, with touch screens... a slide to unlock is an example of a sanity check...

I'm thinking of people with ALS, or spinal damage.

Alternate actions performed by gesture, will need to be categorized by how dangerous they are.

That is the main point I am making, and it would be cool if QT supported that.. (I think that KDE will only do it if QT does it.. and QT is moving back into mobile.. this time with touch screens)
Comment 4 Aaron Peterson 2012-01-07 08:19:59 UTC
This would sure help with the transition to touch screen computing,  where we have sliders and other gizmos to make sure we are not a cat before doing unsafe options.

Perhaps this is an upstream thing for QT?
Comment 5 Nate Graham 2022-04-26 17:06:54 UTC
This isn't something that's really possible to do at the window manager level. It would have to be done in each individual app to avoid stomping on apps' expected actions and breaking some of them.