GNOME Bugzilla – Bug 358731
Single-click mode for all Gnome apps
Last modified: 2018-05-03 21:25:44 UTC
please provide a possibility of singleclick on all GTK applications. The doubleclicking is annoying. please, please, please, please. Other information:
I'm assuming that this is a referring to the file chooser and marking it as a duplicate accordingly. Most other places where GTK+ requires a double click, a single click has a different meaning. In a text entry field a single click positions the cursor, a double click selects a word. So you can't just change double clicks to single clicks all over the place and have it work. *** This bug has been marked as a duplicate of 121113 ***
I do not think that this is a dupe of 121113. That bug specifically asks for single-click behaviour in the file chooser, while this bug specifically asks for all GTK applications. Windows, XFCE, and KDE all allow the user to select a single-click mode, in which the concept of a double click does not exist (excepting the text selection as mentioned in Comment 1). This bug is a request for such a mode in GTK apps. For example, gucharmap needs a double click to move characters to the "Text to copy" field (or a drag and drop). This bug requests that that be changed to a single click in a universal fashion that would affect all GTK apps. This bug is actually a critical accessibility issue for those of us who cannot double click due to disability. For the same reason, we may have difficulty using drag and drop as well. Please reopen. Thanks.
If there's a bug in gucharmap, please file it against gucharmap, separately.
I know of no bug in gucharmap. I was giving an example of a place where a Gnome app requires a double click. There are literally thousands of such places, and some users with disabilities such as myself cannot perform this action. That is why _this_bug_ exists, to request that Gnome have a single click mode as found in Windows, KDE, XFCE, and other desktop environments.
(In reply to comment #4) > I know of no bug in gucharmap. I was giving an example of a place where a Gnome > app requires a double click. There are literally thousands of such places, and > some users with disabilities such as myself cannot perform this action. That is > why _this_bug_ exists, to request that Gnome have a single click mode as found > in Windows, KDE, XFCE, and other desktop environments. then: a) this bug is titled and filed incorrectly and b) you should either REOPEN this bug or open a new one with a proper title and description, and then have per-application bugs which block it. assigning the "add a single click mode to every application" bug to gtk+ has no point; gtk+ can only do so much, and the rest is up to application developers.
Thank you, Emmanuele. I do not have the appropriate permissions on the Gnome bugtracker (most of my contributions are to KDE, where I do have the proper permissions). Please retitle to "Single-click mode for all Gnome apps" and refile as you see fit. I will file blockers. To whom must I speak to get blocker-marking privileges here? To be clear: this bug requests a central gnome-control-center option to put all Gnome apps in Single-click mode. I would recommend that it be placed under the Mouse section to be consistent with other desktop environments which have this mode. Thanks.
Created attachment 151264 [details] KDE mouse settings dialogue Here you can see the KDE mouse settings dialogue, specifically the configuration for single click. This affects _all_ KDE apps, including the KDE file manager, email client, web browser, PIM suite, music and video players, etc.
As talked in IRC with #usability people, this is a valid accessibility issue; reopening
If it's for all applications, why does it say "Single-click to open files and folders"?
> If it's for all applications, why does it say "Single-click > to open files and folders"? This bug (feature request) has nothing to do with the existing Nautilus feature that you mention. This bug requests a Gnome mode in which there does not exist the concept of a double click for any application. Such a mode is available in other Desktop Environments, as stated above. Additionally, it is an accessibility and a usability issue.
Dotan, I still don't understand how this mode works. E.g. if single-click would do someting else as double-click?
In Single-Click Mode the concept of double-clicking in Gnome applications would not exist. I do not have Gnome installed at the moment (because of this issue) but I'll give an example. The Gnome app F-Spot requires the user to double-click on a thumbnail to view the photo larger in the interface. In single-click mode this would not occur: a single click would open that photo. You could argue that what I have described is a feature request for F-Spot. However, the Single-Click modes in KDE, Mac, and Windows affect _all_ applications associated with that environment. There simply is no longer a concept of a double click. This is an important accessibility issue. In addition to RSI, there are other conditions in which a double click is difficult or painful. This may be a toolkit issue, I don't know. Whatever handles the double-click event is the component for which this bug should be filed. Thanks.
> Most other places where GTK+ requires a double click, a single click has > a different meaning. In a text entry field a single click positions the > cursor, a double click selects a word. So you can't just change double > clicks to single clicks all over the place and have it work. There does not need to be any change in the behaviour of text fields. However, in the case of Single-Click Mode, a single click does what double-click does in Normal Mode (activates or opens an item). The Normal-Mode single-click action (usually select) is disabled.
In the Mouse Preferences dialog on the Accessibility page, I see a checkbox whose label is 'Trigger secondary click by holding down the primary button'. When that checkbox is checked, a Delay left-right slider becomes enabled in which you can specify the duration that the primary button must be held down. Does this address your needs?
Created attachment 161021 [details] screenshot of the mouse accessibility options Dwell click might also be an option.
Thanks for the suggestions, Joanie, but introducing such unnatural workarounds such as dwell click is not better than the original problem. Although it would solve the problem of painful double clicks, it is unnatural, cumbersome, and influent to have "dwell" or "delayed" clicking. Every other desktop environment has a single-click mode that is intuitive, easy to use, and provides immediate feedback and response.
You are never going to get this behaviour in "all" apps. Its not even true that on KDE all apps behave this way (perhaps most KDE apps do, but thats not all apps by any means). In addition, OS X doesn't offer this as an option at all. So, at best, you might get the behaviour you want in, say, Nautilus. That won't address the way that Inkscape or GIMP or Blender or OpenOffice or Ardour operate. The notion of a single-click to select an item and a double-click to open it is pretty deeply builtin to quite a few computer/human interface models. Congratulations to KDE (and perhaps others) for coming up with some way to avoid this, but its frankly very hard to see how anyone who uses this model of interaction would ever make multiple selections of objects in any kind of graphical browser if a single click opens the clicked object. Asking for a "desktop-wide" change in the HiG that would make a working style available that favors single click but simultaneously makes multiple selection more difficult seems a little unlikely.
Paul, it seems that your objection to the feature is to enable multiple selections. Is that the only objection, or are there others? The issue of multiple selections is addressed in several ways. In XFCE, KDE <=3, and Windows <= XP the user can select multiple files with the rubber band (drawing a rectangle with the mouse around the files to select) or with keyboard shortcuts: Shift-click and Ctrl-click select files and add to the current selection. Additionally, in KDE 4 and Windows >= Vista the file manager (and other apps such as KDE's Digikam) have "persistent selection", an area of the icon that the user can click which will select, not open, the item.
Paul Davis: Which KDE apps require a double click when KDE is configured for single-click mode? I use almost all KDE apps (including their media player, office suite, PIM, text editor, file manager, desktop environment, and others) and do not know of a place where a painful doubleclick is required. I single click to activate, and rubberband (drag a rectangle around items) to make multiple selections. Alternatively, I can make multiple selections with the Shift and Ctrl keys, or the "+ sign" persistent selection option (Gnome does not have this, though). Also, the mode would be an option, not mandatory, so the argument that double-click behaviour is "pretty deeply builtin" is not contradicted. Furthermore, I dare say that the MS Windows UI (taskbar on bottom, single unified menu, etc) is "pretty deeply builtin" for many computer users, yet Gnome rightfully disregards it in favour of something better.
Dotan: you seem to want single click (with or without modifiers) to both (a) select an item and (b) open an application. Which one is it?
> Dotan: you seem to want single click (with or without > modifiers) to both (a) select an item and (b) open an > application. Which one is it? > Depends on context. In the context of the File Manager and the Desktop, a single click should open the file/application. Selection would be done by rubberband (clicking outside an icon then dragging around the icons), as is currently implemented, and by Ctrl/Shift-click, as is currently implemented. In the context of the File Chooser (save/open dialogues) a single click on a directory should change to that directory, and a single click on a file should select that file. In the context of Fspot, a single click should display the image (this may already be the case, I do not have access to a current Fspot but the devs were interested). In the context of a media player, a single click should play the media. In short, a single click should perform the default action in all cases. It is healthier, more intuitive, easier and faster to perform. Thanks.
As a possible implementation, what about modifying GdkEventType to include a GDK_BUTTON_ACTIVATE that basically means "double-click, unless in single-click mode, in which case single click"? Have an XSettings property for single-click mode. The code that's firing off button-press-event would insert an extra one for GDK_BUTTON_ACTIVATE, either after the GDK_2BUTTON_PRESS normally, or after the first GDK_BUTTON_RELEASE in single-click mode. The GDK_BUTTON_ACTIVATE event would not be fired if event.type indicates a modifier key is pressed. If you have something like a GtkTreeView or GtkIconView (or one of the many custom tree/icon/tile-view widgets out there) where click=select and double-click=activate, you should watch for GTK_BUTTON_ACTIVATE. If you're doing something else on double-click (e.g. selecting a word in a text entry), you should continue using GDK_2BUTTON_PRESS. Modifying GdkEventType is an ABI break, I think. So this method would have to be on a point-oh. Alternatively, GtkWidget would have a completely different signal ("button-activate"?) with roughly the same semantics. That wouldn't require a break.
As has been mentioned a number of times already this bug is very hard to evaluate or fix as it is. We now have the ability for icon view and tree view to activate items on single click. I think we should recommend that applications do not rely on double click. We don't want to have a setting for this. However, these changes will have to be done by each application separately. A switch from double to single click activation really requires a new design and can't be done behind the back of the application. If there are other parts of the toolkit that work only with double click please file those separately and we'll find a solution for them.