GNOME Bugzilla – Bug 121113
File chooser requires double clicking
Last modified: 2018-05-02 13:52:41 UTC
When clicking a folder or filename in a file selector to open it, it would lead to a more consistent desktop if it followed Nautilus' "Single/Double click to activate" option.
This would depend on having an XSETTINGS key for a desktop-wide setting of the double-click behavior. GTK+ can't pull configuration information from GConf, which is what Nautilus uses. I'm not sure this is a bug at all, though. The file chooser is different from the file manager; in the former you click on a file, then click the OK button to accept the operation.
Could Nautilus' option be deffered to a GTK+ option? The file chooser is in a sense like a mini version of Nautilus' file browser functionality. Although you can click OK to select a file, you can't open a folder without double-clicking or using the keyboard. In MS Windows file choosers follow the Explorer's click policy.
So, if you have single-click enabled in Windows, what happens when you - click on a file in the file selector - click on a folder in the file selector ?
Sorry, I forgot about this for a while. If you single-click with the "single click activates" option enabled it has the same effect as double clicking in the normal mode. So single-clicking a folder descends into the folder, clicking a file selects it and closes the dialogue as if OK were clicked.
*** Bug 135480 has been marked as a duplicate of this bug. ***
Created attachment 27732 [details] [review] Add global single click xsetting (against GTK+ 2.4).
Created attachment 27733 [details] [review] Implement single click for GtkFileChooser (against GTK+ 2.4).
Can this be committed to GTK+ 2.4 as well? AFAIK the next GNOME version will be 2.4-based so maybe its a good idea to add this to GTK+ 2.4 instead of committing it to HEAD. regs, Chris
New API goes to 2.6.
*** Bug 140826 has been marked as a duplicate of this bug. ***
Bug 140826 also wants the bookmarks part to follow the single/double click behaviour. Does the patch also do that? Also note bug 148828. That reporter wants the bookmarks part to always use single click and gives some arguments for single click.
When trying to implement this using the button-release-event, I had to learn by hard that DnD heavily interferes with the button-release-event. Can anybody hint me at documentation that clearly states how to implement that? regs, Chris
*** Bug 151096 has been marked as a duplicate of this bug. ***
Ping?
any news on this bug ?
If there was news on this bug, it would be on the bug!!! As for comment #12, no idea what is being asked about. Anything that is implemented in nautilus can also be implemented in the file chooser. If you aren't clear how nautilus is implemented, you can look at (but not copy, since it's GPL) the source code.
Created attachment 36687 [details] [review] Implement single click for GtkFileChooser (against HEAD). OK, I rewrote the whole 2nd patch against the FileChooserDefault. What the new one does is: - Implement single-click behavior for shortcut list and file list - Add a shortcut popup menu with a remove item, because else you couldn't remove shortcuts with single-click - Fix a bug where the first file that was clicked after construction of the popup menu didn't have a sensitive "Add to Shortcuts" item I had to setup three GtkSetting signal handlers for different xsettings and poke around with multi-GdkScreen setups with different hand cursors. Sorry that I wasn't able to provide a smaller patch. Because it is so big and was much work, I'd appreciate if it could be reviewed quickly. A sidenote: I couldn't resolve an issue where gtk_tree_view_get_path_at_pos seems to return TRUE if the cursor is on the column header. It is probably worth a new bug report.
On a sidenote, I think that Nautilus gconf key /apps/nautilus/preferences/sort_directories_first should also be moved to gtk and used by the filechooser too.
*** Bug 308224 has been marked as a duplicate of this bug. ***
> New API goes to 2.6. I'm using GTK+ 2.6 and there is still no progress ? Any news ? What about 2.8 branch ?
Other things took priority. And it is too late for 2.8 now, too. Maybe query bugzilla for bugs on the Small API/Medium API/Big API milestones sometime, to understand why things sometimes take a long time.
*** Bug 309858 has been marked as a duplicate of this bug. ***
it is true that other systems close the window and consider the user clicked OK when clicking on a file in single-click mode, however in the GTK file selector that would prevent selecting multiple files at the same time. The reason that it's not a problem with other file openers is that they have icon-view not list-view style openers, so you can always click between the icons and select several of them (by drawing rectangles with the mouse). but i guess this is an issue for almost nobody in the real world. my wish would be that it would be single click to descend in a folder, but otherwise same behaviour as now, no "single clicking a file opens it and closes the dialog". but it's just a personal preference... feel free to ignore it.
Emmanuel: You can still press ctrl and select in single-click mode to select multiple files.
comment #24: good point. i was mostly trying to find an excuse to justify the behaviour i'd prefer, actually :-) another one maybe: when there is a preview in the file opener, for instance gimp previews pictures for the selected listview item, that would require keyboard navigation to see the previews of files, if single-click will open the file.
The single-click can be implemented only for selecting directories, and if is the file selected -- only one click will open selected file. Now if is file selected, you must double click to open it -- that's unavailing if it's file selected yet.
*** Bug 317725 has been marked as a duplicate of this bug. ***
Note that Bug 317725 addresses a slightly different issue. There it's about the left half of the dialog, here it's about the right half.
It would be nice to have common interface for click policy. What about closing the bug and move it as target for new Portland project (http://portland.freedesktop.org/wiki/)?
*** Bug 358731 has been marked as a duplicate of this bug. ***
(In reply to comment #29) > It would be nice to have common interface for click policy. What about closing > the bug and move it as target for new Portland project > (http://portland.freedesktop.org/wiki/)? Please don't close this bug - it's really important usability bug, lots of newbies can't understand when they should use single click and when double :( If GTK FileChooser would work with single click then live was easier for computer newbies.
Urgh, this bug is 4 years old, and Christian made patches available (comment #17 for example). What actually IS blocking this? Is it incompatible with gtk 2.11? Who can I buy beer for so that this issue vanishes into Ancient History?
Can someone please see if the patch applies to svn trunk?
Hello all, I doubt the patch could be applied to svn trunk :-( I may be wrong, but having a look at the last attached patch, it is based on revision 12377 of gtk/gtkfilechooserdefault.c. Here is a diff between this revision and the last committed revision : http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkfilechooserdefault.c?r1=12377&r2=18249 I think that creating a new patch from scratch will be quicker than trying to merge this old one into the trunk ... I am also very interrested by this feature. I hope it helped ! Cheers, Charles-Henri
*** Bug 481385 has been marked as a duplicate of this bug. ***
I just discovered an inconsistency in the file chooser itself that's somewhat related. Places only require a single click while folders require a double click. In Nautilus they both require a double click (don't know how Nautilus behaves in single click mode).
In nautilus single click, they both require a single click. By the way, I consider the recent change of behavior of the file chooser to be a great improvement. As there is pretty much nothing to "select without activating" the left column items for, there was no reason (that I can think of) to use double click there. Newbies and click-savers rejoice.
I've just discovered bug 148828. Sorry for the spam. :/
*** Bug 511850 has been marked as a duplicate of this bug. ***
My old patch was of poor quality and needs work. I'll rework it.
Created attachment 106057 [details] [review] Proposed patch The attached patch is a first attempt for a proper implementation. It moves the tree view-related single-click activation bits to GtkTreeView, adds a _gtk_tree_view_set_single_click_activate() API, and just leaves the cursor handling to the file chooser. ATM we display a hand cursor for the file list when hovering, which resembles the look & feel of a web browser. However, we don't display the cursor for the bookmark list, so I'm not sure whether this inconsistency is actually intuitive. I'm just trying to resemble Nautilus' current behavior.
Ping.
Marking attachment as needs-work. Just replicating the current Nautilus behavior is suboptimal, because it is not 100% user-friendly either. We will have to work on a complete behavior specification before getting this into GTK+.
Let's see if better tools can make me a more responsible maintainer :) I've put this in a git branch: git clone http://www.gnome.org/~federico/git/gtk+.git cd gtk+ git checkout origin/bgo121113-single-click-activate I split the patch into three commits: one for GtkSettings, one for GtkTreeView, and one for GtkFileChooser. Manny, do you want to work from there?
What additional work needs doing (re. comment #46)? I've just modified Christian's patch from #44 against my distro's current source, and it seems to work OK for single selection; don't know about multi-select yet. This particular issue is a major usability issue with GTK for me personally, and I'm keen to see resolved in trunk somewhat sooner than the 5 years (!!) it's been since the initial report. If needed, I /can/ maintain a personal patchset but I really, really, really don't want to go down that route! So, what can we (I?) do to help resolve this once and for all?
*** Bug 543453 has been marked as a duplicate of this bug. ***
Sorry, change of url: http://gitorious.org/projects/gtk/repos/mainline/logs/manny-bgo121113-single-click-activate
*** Bug 563625 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > So single-clicking a folder descends into the folder, clicking a file > selects it and closes the dialogue as if OK were clicked. How do you do multiple select ?
(In reply to comment #52) > (In reply to comment #4) > > So single-clicking a folder descends into the folder, clicking a file > > selects it and closes the dialogue as if OK were clicked. > > How do you do multiple select ? Control+click, as in Nautilus.
*** Bug 598672 has been marked as a duplicate of this bug. ***
(In reply to comment #46) > Marking attachment as needs-work. > > Just replicating the current Nautilus behavior is suboptimal, because it is not > 100% user-friendly either. We will have to work on a complete behavior > specification before getting this into GTK+. It's been well over a year since this comment, so isn't it about time someone decides that: * There's a fairly easy fix to give a clear improvement over the current behaviour and a patch set is already available * It's been over a year since it was suggested there's room for further improvement, but still nobody seems to have actually thought of how (and for God's sake let's not mimic Windows' hover-to-select) * This bug is more than 6 freaking years old! So just go ahead and fix it!
Hello, Will this critical accessibility bug ever be patched ? This bug make gnome unasable for people who can't make double click. :( I know there is mousetweaks, but it's a nasty hack to work around a wrong default behaviour, what does that mean ? For people who don't know about the ctrl/shift thing, a simple message in the status bar or a tooltip could help.
Just adding my voice and encouragement to fixing this bug. 6 years.... come on!!!!
*** Bug 619528 has been marked as a duplicate of this bug. ***
The duplicate bug #619528 mentions making this a GSettings option for a future version of GTK+; this is certainly a good idea. This way both Nautilus and GtkFileChooser can share the same configuration option.
I rebased Manny's patches and put them in the bgo121113-filechooser-single-click-activate branch in git.gnome.org. Can someone please test this? This doesn't use GSettings yet; just GtkSettings as in Manny's original patch.
*** Bug 561969 has been marked as a duplicate of this bug. ***
Works on my machine :) Any chance of getting this into trunk before the 7 year anniversary...?
I tried Gnome with Ubuntu 10.04 and there is still no single-click in GTK-firefox-open-dialog (GtkFileChooser). Also no ALT+LEFT for return! It's unbelievable. After all the years. Linux is still unusable...
As there seems to be a patch available, could one please push it to git ? Even my wife is complaining about the current inconsistent behaviour. Greets Marcus
Anything new at this point? A mix of single and double click is very inconsistent :-( Cheers Sascha
(off topic rant) Importance: High enhancement Target: Small API Status: Assigned (and worked on by assignee) Anything new? Heh, I've given up on Gnome now and moved to KDE; anybody want a bet that the desktop computer becomes obsolete prior to this being fixed? 7 *years* active, for a high-priority bug with an initial patch supplied 3 years ago. Not even an acknowledgment that the bgo121113-filechooser-single-click-activate branch was compiled & tested OK, nor a response to an offer for help (comments 48 & 60 from me.) This ticket has had a "can't do / won't do" attitude associated with it from the start (see comments 1 & 3) by the maintainer. Frankly, if the [commercial] development team for whom I have responsibility behaved like this then it would be unlikely that we had any customers left (nor that we'd have the same team members ;) ) So go on maintainer, surprise me and do something productive with this ticket!
To all: I can understand frustrations, but please refrain from ranting. Your account will likely end up being disabled. Note: I'm one the GNOME bugzilla maintainers + I do not code
I can understand the maintainers not wanting to do anything to the current release because of GNOME 3 coming up, but I think they used that excuse with one of the 2.x releases. This should already have been done for the upcoming release of GNOME 3 but maybe it's not too late. Is GTK going to continue to use xsettings? The front-end setting will need migration from gconf to gsettings though. If the developers still won't do anything about this perhaps mirrors of this bug could be opened in some of the major distros. I think Ubuntu in particular would welcome this improvement in usability. If a few start using the same patch it might persuade upstream to accept it.
(In reply to comment #68) > If the developers still won't do anything about this perhaps mirrors of this > bug could be opened in some of the major distros. I think Ubuntu in particular > would welcome this improvement in usability. If a few start using the same > patch it might persuade upstream to accept it. There's a bug report about this issue in Launchpad. See https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/11544
*** Bug 603168 has been marked as a duplicate of this bug. ***
GTK3 and GNOME3 are well established now, but still I see no sign of this bug being addressed. Browsing dconf-editor I noticed that the file chooser already has its own set of gsettings, so surely it's quite elementary to add one for single-click, switch nautilus over to it and update one of the patches that already exists to implement the behaviour in GtkFileChooser. However, I also agree with those who are arguing for a global option to eliminate double-clicking across the entire GTK/GNOME desktop. Still just as easy except some other applications should be updated too.
I spent a half an hour reading whole this thread, and I really didn't understand why after all these years the issue still not fixed. Why proposed patches still haven't been applied even in gtk3?
Created attachment 232189 [details] [review] Single click This is an updated patch to work with GTK3. It also finally uses GSettings. Note: Nautilus needs to be updated to use this setting also.
*** Bug 667995 has been marked as a duplicate of this bug. ***
Given that after nearly a decade and several releases of Gnome the maintainer has failed to do anything useful with the patches provided by others despite many releases of Gnome and offers of help... can this bug just be closed as "Maintainer doesn't give a ****" ? See comment #66 - amusingly enough, the desktop computer really is heading for obsolescence now with the rise of phones and tablets. Yes, I'm sure I'll get banned for venting; but after this long, who cares??? This ticket is a joke, and clearly the maintainer has absolutely no intention of doing anything about it.
I don't think having an option to make the file chooser work with single click is a good idea. I would rather make it work reasonably well with single click by default. I don't think it is as easy to do with with Nautilus so I would do this independently of Nautilus for the moment. There are a few ways we could go about this but one is: * descend directories on single click - this is consistent with sidebar and pathbar * add a back button to the dialog like we have in nautilus - this is made more important if we descend more aggressively * just select file on single click - in order to show a preview * treat double click activation as an easter egg and depend on dialog buttons for explicit activation * treat the "viewed" folder as the selected folder in the *_FOLDER modes
Having Nautilus change the click setting is easy the Gsetting work is in my patch. It will be very easy to update nautilus to use the same setting. It already has one it just needs to share the new filechooser setting from my patch. This matches the way we now share the hidden files setting.
Is there something wrong with Timothy patch, otherwise, why isn't it incoporated ? Please give me link to documentation on the gnome patch integration process if you have. Just selecting as a default behaviour when you use primary button seems right in a file chooser. However a behaviour consistent with what happen in the file browser (or the other way around if you prefer) also sounds like a good idea.
I modified the patch to apply to gtk+-3.6.3. The big problem I had was, that no key "click-policy" appeared in dconf-editor. After some fiddling I found out I can set it with dconf write "/org/gtk/settings/file-chooser/click-policy" "'single'" Now the file dialog works with single click - with the limitation that files immediately after clicking them get opened. But now the key in dconf-editor does not show the descriptions... So probably some sort of update/conversion-scripts need to be run after installing the patched gtk+?
My patch is meant to be applied with a patched version of Nautilus that will create the "click-policy". Its very simple to update Nautilus to use this setting I just haven't created the patch yet as I'm waiting for feedback from the Gnome devs on this patch first.
I've pushed Timothy's updated patch to the bgo121113-filechooser-single-click-activate branch. The patch is split into three commits: one for single-click in GtkTreeView, one for the GSettings schema, and one for the file chooser itself.
Yay, yet another old-timer going away! ;-)
Shouldn't Nautilus be patched too? I think it would be best if it simply has its own setting replaced with the Gtk one, then it can stay consistent with FileChooser and act as a convenient front-end for setting the global option without having to make a potentially more disruptive change to gnome-control-center.
> Yay, yet another old-timer going away! ;-) Federico did the same thing 3 years ago... see comment #60 Fingers cross(compile)d for this time though ;)
Is this finally fixed? can the bug be closed then?
AFAIK the patch is still sitting in a branch doing nothing. Please can a developer tell us whether they intend to merge it soon, and if not, why.
I'm not sure what else Federico wants done for these patches to finally make it into master. Maybe some more user testing first? Once Federico agrees the patches are ready I will create the GSettings patch for Nautilus.
*** This bug has been marked as a duplicate of bug 722211 ***
Reopening/unduplicating from the overly vague "improve the file chooser design" bug #722211, which was marked as fixed, whereas the single/double-click behavior remains inconsistent between Nautilus and the GTK+ FileChooser.
I think there is no consensus that we have to eschew all forms of double-click from the UI. And there is also no consensus that any difference in behavior between nautilus and the file chooser is an 'inconsistency' to avoid - they are different UIs for different tasks. An option to choose between single-click and double-click is not very attractive. Double-clicking should never be the only way to trigger an action. But that is not the case in the file chooser, anyway: You can select a folder, and use the open button to navigate into it, and you can select a file and use the open button to accept it. No double-clicking required. So, if you ask me, reopening this bug was not required.
(In reply to Matthias Clasen from comment #90) > I think there is no consensus that we have to eschew all forms of > double-click from the UI. And there is also no consensus that any difference > in behavior between nautilus and the file chooser is an 'inconsistency' to > avoid - they are different UIs for different tasks. There is consensus that double-clicking is difficult for people with certain disabilities [1]. And there are obvious similarities between the file chooser and Nautilus. In Windows there is more consistency between the two. Slavishly copying Windows (or OS X) was never a good idea, but it doesn't mean we have to ignore or do the opposite of every little good feature. > An option to choose between single-click and double-click is not very > attractive. Why not? This option already exists in a major GNOME component. If there's a good reason for this option in Nautilus there's a good reason to have it in file choosers, and any other widgets showing lists of items that can be selected and opened. Or do you think Nautilus should be made double-click only too? > Double-clicking should never be the only way to trigger an action. But that > is not the case in the file chooser, anyway: You can select a folder, and > use the open button to navigate into it, and you can select a file and use > the open button to accept it. No double-clicking required. It's long-winded and clumsy though, especially for the sort of people who have problems with double-clicking.
Having recently given beginner training courses to elderly people, I can add that even without any particular disability, having inconsistent behavior in mouse clicking is a major hurdle. I had three different group, and all three had difficulties with both double clicking and understanding when you should or not use it. It often leaded them to always double click, even when not necessary. The main button should always launch the main expected function. The problem is not only to have a non-double click path to the function. It's a matter of UX consistency.
Besides, if we just applied the patch that makes the filechooser follow the Nautilus setting: * people who have configured Nautilus to use single click will be happy to notice the filechooser acts the same way (just as file-roller already does). * people who didn't change anything and thus have double click in Nautilus won't notice a difference So everyone wins.
(In reply to psychoslave from comment #92) > Having recently given beginner training courses to elderly people, I can add > that even without any particular disability, having inconsistent behavior in > mouse clicking is a major hurdle. I had three different group, and all three > had difficulties with both double clicking and understanding when you should > or not use it. It often leaded them to always double click, even when not > necessary. That's true, I've often noticed people who are unfamiliar with computers end up double-clicking everything, including browser links.
(In reply to Alexandre Franke from comment #93) > Besides, if we just applied the patch that makes the filechooser follow the > Nautilus setting: > * people who have configured Nautilus to use single click will be happy to > notice the filechooser acts the same way (just as file-roller already does). > * people who didn't change anything and thus have double click in Nautilus > won't notice a difference I think there should be a new setting in a more appropriate namespace [1] and Nautilus should be changed to use it. However, access to the option could be left in Nautilus' config dialog so existing users don't get confused. But I think the main way of setting it should be in the Mouse & Touchpad settings. Universal Access could be another possibility, but that section's already quite busy and this isn't purely an accessibility issue. [1] In fact, it could be a good idea to apply this not only to GTK, but make it part of XDG and see if it's possible to get a single option shared between GTK/GNOME and Qt/KDE.
(In reply to Tony Houghton from comment #95) > But I think the main way of setting it should be in the Mouse & > Touchpad settings. Universal Access could be another possibility, but that > section's already quite busy and this isn't purely an accessibility issue. > Note that there was recent activities on the mouse and touchpad settings[1]. Also I have been told that there are planes to move globally to "selecttion pattern", like you may find in Clocks, Contacts, and so on. [1] https://wiki.gnome.org/action/diff/Design/SystemSettings/Mouse?action=diff&rev1=33&rev2=34 > [1] In fact, it could be a good idea to apply this not only to GTK, but make > it part of XDG and see if it's possible to get a single option shared > between GTK/GNOME and Qt/KDE. Excellent suggestion, as the behavior should indeed remain consistent whatever toolkit the software use.
(In reply to psychoslave from comment #96) > Note that there was recent activities on the mouse and touchpad settings[1]. > Also I have been told that there are planes to move globally to "selecttion > pattern", like you may find in Clocks, Contacts, and so on. See https://wiki.gnome.org/Design/OS/SelectionPattern
Just to be very clear, and prevent wrong expectations here: I am not interested in supporting a single-click vs double-click setting in the file chooser. It is not a good solution in nautilus and won't happen here. Also, this bug is very close to the magical 100 comment threshold
> I think there is no consensus that we have to eschew all forms of double-click from the UI. And there is also no consensus that any difference in behavior between nautilus and the file chooser is an 'inconsistency' to avoid - they are different UIs for different tasks. If I wouldn't look at the commenter's profile, I'll think this is a fat troll willing to plague out gnome user's life. Just every single word in this comment is a lie. It's easy to understand it by reading the rest of the comments.
and... the curtain falls. Calling me a liar on bugzilla, and reaching triple-digit comments is enough.
(In reply to Matthias Clasen from comment #98) > Just to be very clear, and prevent wrong expectations here: I am not > interested in supporting a single-click vs double-click setting in the file > chooser. It is not a good solution in nautilus and won't happen here. Also, > this bug is very close to the magical 100 comment threshold I don't think any other GTK+ developer so far has said that they think a convenient alternative to double-click is wrong, and I thought it was going to be implemented in GtkTreeView or something, not just the file chooser. Are you responsible just for GtkFileChooser (besides a few other things that aren't relevant to this bug) or are you also responsible for GtkTreeView or somehow else in a position to dictate this policy across the entirety of GTK+ on your own?
> I don't think any other GTK+ developer so far has said that they think a > convenient alternative to double-click is wrong I haven't said that either, but I'm done replying to this bug. You can keep it open as long as you want.
gmRUQ7I8 obviously is a spammer posting with a throwaway mail address. Please don't get upset because of his comments. If he gets what he wants (close this bug and never implement a feature many people apparently would like to see in GTK+) everyone will lose.
If you want traction on this, you need to talk with a designer. In any case, if you like, please convince me why this is important and I'll see about making an argument when I meet the core developers at GUADEC. One thing to keep in mind is that when people request bug fixes or behavior changes, you need to figure out how it affects the entire system, and not focus primarily on nautilus or the file chooser. GNOME tries to enforce consistency throughout the whole platform. So you'll note that Jon mentioned that it would be best to go all in on single click vs double click because if there is inconsistency it will be problematic. Now, you could argue that the touch story would be complicated in a double click world. Today, I can't touch and activate anything with touch that easily. Anyways, I'm just trying to show people how to work with GNOME developers.
Thanks for your input, Sri. To be honest I have no problem with double-clicking, I just prefer to use the single-click option when available (but not in Windows, where it's ruined by the awful hover-to-select model). But I have strong feelings about this bug, because I had to work so hard (and long!) to convince some developers that I had a valid point, and then saw it all being dismissed. It made me feel that GTK+ developers don't care what I and several other users think. I do think that GNOME 3 represents progress over GNOME 2 and still use it in preference to KDE, but you have to admit that many users hated it and had the same feeling that they were being ignored by the developers. I keep telling myself I'm overreacting, but I've been made to question whether GTK+ has a future and is it therefore worth continuing to develop with it.
(In reply to Sri Ramkrishna from comment #105) > If you want traction on this, you need to talk with a designer. In any > case, if you like, please convince me why this is important and I'll see > about making an argument when I meet the core developers at GUADEC. I'll be at GUADEC too and I'm one of those who care about this, so I'll be happy to discuss this with you and then with GTK+ maintainers.
The problem seems to be that there isn't strong enough agreement on the best way to "fix" this, but I think just giving up and doing nothing is one of the worst options. I hope one thing we all agree on is that consistency is a high priority in UI design. IMO Nautilus and the file chooser perform very similar roles, as do many other GtkTreeViews - they present a set of objects that can be selected and/or opened or activated. In a sense Nautilus is a file chooser for the entire desktop environment, with some extra actions available; in MS Windows the standard file chooser is identical to the Explorer. However, in some cases there is no such distinction, such as selecting pages in a config dialog. Most would be programmed to respond to selection callbacks rather than activation events because the activate-on-single-click property was only added in 3.8. But with single click to activate the app can receive both a selection callback and an activation signal, so applying the option to all GtkTreeViews wouldn't cause them to break. As I said before, I don't have a problem with double-clicking personally, but I do think users who do would appreciate a consistent gesture that isn't significantly slower. https://wiki.gnome.org/Design/OS/SelectionPattern mentions long clicks. I hadn't thought of that before, but I think I could live with that as an alternative to double-clicking. It has the advantage that you could probably get away with just turning it on all the time without an option to turn it off, although I suspect there'd be a strong demand for an option to set the time period (and a very long time would effectively disable it). What do you think about punting this to XDG? Should I post to their mailing list or open a wishlist bug there?
Short/long press may cause problems for some people, but that should be manageable in accessibility parameters. Having checkbox along the file icon looks like an alternative. It could avoid the need to click on the selection tool to make them appear, but maybe there are some none obvious reason to add this step. After all icon could come with both a checkbox and a launch/enter button of the same size. You could actually even drop the checkbox and keep single click on the main element area used to select it, while adding the checkbox size icon to launch main action, the bottom toolbar providing further options. This way you may even have already several selected item and launch only the main action on a single one. For example you selected several text files but would like to check the content of a single one without losing your selection: you just click the "launch" button of the relevant item.
If people find the long press acceptable, then let's agree on that. It's already in plan, of course.
I do accept it. Survey "people" acceptance would require a way to expose some voluntary beta testers to new design ideas. That would require a deployment infrastructure that, as far as I know, we currently don't have. @Comment 109 Tony Houghton As already stated, I'm favourable with up-streaming that to XDG, If you do so, please provide a link on this bug report to the relevant mailing list archive thread or to the wishlist bug.
Dear Sri Ramkrishna, Please read the rest of the comments on this bug. There are a lot of angry people, who will treat this kind of "fix" as a mockery. I, personally, can't understand what is a problem to fix this once and for all. I don't care how this option will be enabled, by modifying configuration file or by gsettings, or by another unusual way. I used to use those configuration methods, as a plenty of brilliant gnome 2 functionality was disposed since gnome 3 release, and in order to be able use it you have to do a lot of monkey work. Seems I don't have a lot of options, if I want to use Linux on desktop. If you claim you have community, then why this very important long living issue depend on single person? While you're looking for "proper" way to fix this, you literally do the mockery on gnome users. This must be fixed as soon as possible, doesn't matter how. You can even open another bug to fix this temporary implementation in the future, but it can't be left as it is. I understand that there are a lot of interesting and fascinating tasks over there and you better go to do something else, but you need to clean some dirt from time to time.
(In reply to psychoslave from comment #110) > Having checkbox along the file icon looks like an alternative. It could > avoid the need to click on the selection tool to make them appear, but maybe > there are some none obvious reason to add this step. After all icon could > come with both a checkbox and a launch/enter button of the same size. Using a checbox for selection is a good idea; I think I prefer it to the long press idea actually. I should have thought of it before, because there are some screenshots of that on the page linked in comment #97. The only disadvantage is that it could look a bit unattractive with the large icon/tile layout. > You could actually even drop the checkbox and keep single click on the main > element area used to select it, while adding the checkbox size icon to > launch main action, the bottom toolbar providing further options. This way > you may even have already several selected item and launch only the main > action on a single one. For example you selected several text files but > would like to check the content of a single one without losing your > selection: you just click the "launch" button of the relevant item. I don't like that so much. A checkbox for selection is well-understood, but another button for open/activate etc could seem unfamiliar.
(In reply to psychoslave from comment #112) > As already stated, I'm favourable with up-streaming that to XDG, If you do > so, please provide a link on this bug report to the relevant mailing list > archive thread or to the wishlist bug. I haven't done this, for two reasons. One is that we now seem to be looking for a better one-size-fits-all behaviour instead of providing options. If there was going to be an option to apply across toolkits there would be a clear role for XDG, but without such an option it doesn't seem so relevant. The second reason is that it would help if it came from someone with experience of KDE as well as GNOME and Unity etc. I don't have that experience; I couldn't even get it to work well enough to access any options at all when I tried it in Debian recently.
(In reply to Tony Houghton from comment #114) > I don't like that so much. A checkbox for selection is well-understood, but > another button for open/activate etc could seem unfamiliar. Users are already familiar with having a set of action icons along an item, that something widespread in web and mobile interfaces. Here are some examples : * https://marketplace-cdn.atlassian.com/files/images/com.thed.zephyr.je/ad462b6e-b592-4d1f-a789-bde05067eaf4.png uses: *a pen to symbolize edit * a basket to remove the item * a "E" maybe for "execute" (a gear is a widespread icon for that kind of action) * http://en.flossmanuals.net/newscoop3journalists_en/_all/_booki/newscoop3journalists_en/static/Screenshot84-Publication_list.png * a tool icon for configuration * a red arrow for deletion. * http://www.sm-ms.co.uk/wp-content/uploads/2014/09/Screenshot_2014-09-22-10-15-16.png * http://www.brockmann-consult.de/beam/tutorials/BeamJavaWS/images/ScreenShot034.png Of course users are more accustomed to see this kind of feature in "one item per line list". But the current selection mode already introduce the checkbox associated to big icons. So the UX already started down the path of unusual/innovative behavior. Note that a "…" or "⇩" icon may also be open a larger set of item, for action that would apply only to the corresponding item. * http://eu.montana.edu/d2l/help/quizzes/quiz_reset/images/v102_quiz_reset_002.png * http://help.stoamigo.com/wp-content/uploads/2015/02/Screenshot_2014-12-23-10-02-011.png
Well, note that the previous comment is in fact not really accurately placed on this bug report. Sure it would disappear with such an interface change, but that would be really a side effect. Probably I should put the comment elsewhere, shouldn't I? Let me know if you are aware of where it should belong.
Here I have made a mockup https://wiki.gnome.org/Design/OS/SelectionPattern#Alternative_tentative_Design Regarding the file chooser, having a radio button instead of a check box when the user have to select only one file may be relevant.
I personally find checkbox lists on the web infuriating, at least in the incarnation that forces me to click each checkbox individually, and aim very carefully. Thats the opposite of convenient. We'll have to be careful to avoid reproducing those issues here.
Well if you look at how it's done for instance in GNOME Photos, when you're in selection mode clicking anywhere on the photo you want to select/deselect enables/disables the checkbox.
I installed Windows 10 today and I noticed the new Add/Remove Programs window uses a scheme a little like psychoslave described in comment #110. But an important difference is that the action buttons are hidden until an object is selected, then the item's bounding box expands to make room for buttons underneath. This makes efficient use of overall screen space and reduces mouse movement compared to having fixed buttons in a separate part of the dialog. One potential disadvantage is that items in the list have to be moved to make room for the buttons coming and going and that might be a bit annoying if you're trying to make a multiple selection, but I don't think that would be a serious problem. Another issue is what to do with the buttons when there is a multiple selection. I don't think the selected items should all have buttons, so there's a choice of leaving them on the first selected item or moving them to the most recently selected. The first has the disadvantage of maybe having to move/scroll a long way back to the first item's buttons after selecting the last. The second's disadvantage is that it would exacerbate the nuisance factor I described in the previous paragraph.
(In reply to Matthias Clasen from comment #119) > I personally find checkbox lists on the web infuriating, at least in the > incarnation that forces me to click each checkbox individually, and aim very > carefully. Thats the opposite of convenient. We'll have to be careful to > avoid reproducing those issues here. Even on the web you can make the whole label (or whatever element) binded to your checkbox. Just as said Alexandre. Actually in a web form which is well designed you can also tab/space through it.
In the meantime, I've taken the 'sting' out of double-clicking in the file chooser, by making a single click on the selection do the same as a double click.
(In reply to Tony Houghton from comment #121) > I installed Windows 10 today and I noticed the new Add/Remove Programs > window uses a scheme a little like psychoslave described in comment #110. > But an important difference is that the action buttons are hidden until an > object is selected, then the item's bounding box expands to make room for > buttons underneath. Could you screencast that for us? > This makes efficient use of overall screen space and reduces mouse movement > compared to having fixed buttons in a separate part of the dialog. Well that's seems fine when you want to act on a single element. But how is it managed when you want to select several? Did you look at the mockup I linked to earlier? https://wiki.gnome.org/Design/OS/SelectionPattern?action=AttachFile&do=get&target=alternative-tentative.png It does have icons along each icon for launching individual action. Admittedly, I took too much place with this action icons. They could be placed in line at the right of the icon, while the checkbook could be placed at the bottom left. It would be far more efficient it term of space usage. How would that compare in term of overall screen space and reducing mouse movement with the case you are referring to? > Another issue is what to do with the buttons when there is a multiple > selection. I don't think the selected items should all have buttons, so > there's a choice of leaving them on the first selected item or moving them > to the most recently selected. The first has the disadvantage of maybe > having to move/scroll a long way back to the first item's buttons after > selecting the last. The second's disadvantage is that it would exacerbate > the nuisance factor I described in the previous paragraph. I went really on the opposite side in the mockup: all elements have buttons, selected or not. Probably for the same reason that it's less confusing to have grayed options than showing/hiding them depending on current option states. Having a single action menu without any indication that it will be performed on all elements would be probably confusing.
(In reply to Matthias Clasen from comment #123) > In the meantime, I've taken the 'sting' out of double-clicking in the file > chooser, by making a single click on the selection do the same as a double > click. Thank you for doing something. I'm not sure I get what you mean. Is that consistent with Nautilus behavior?
(In reply to psychoslave from comment #125) > (In reply to Matthias Clasen from comment #123) > > In the meantime, I've taken the 'sting' out of double-clicking in the file > > chooser, by making a single click on the selection do the same as a double > > click. > > Thank you for doing something. I'm not sure I get what you mean. Is that > consistent with Nautilus behavior? I think he means if you click once it selects the item, like the current behaviour, but if you click again on that selected item it opens it. So it's like double-click with an infinite time-out. That seems pretty sensible.
I agree it's sensible. However, let's note that it's not consistent with Nautilas in single click mode. Now I don't know when the change will operate in a stable release, and whether we have time to find a solution which bring more consistency, whether "little fix" like this one, or "changing the whole design".
It would help alot, if singleclick on a folder icon would directly go into that directory. I do not mind to do any sort of double click (short timeout, infinite timeout, or select + click "open"-button or similar) on files. So the user still can select multiple files. Don't know how to deal with select-multiple-dirs, but that's a case I never came across... It's that double-click-orgy when navigating through the (sub)dirs that drives me mad.
There is always ctrl+click for adding/removing a single element in a selection. But it's hardly discoverable if you don't read the documentation. A little message that give the hint would be nice. For example a "mouse hover" message, or a message on the bottom of the selector dialog.
(In reply to psychoslave from comment #127) > whether "little fix" like this one, or "changing the whole design". "Changing the whole design" is something for a very separate bug report (and this report has gotten pretty off-topic by now).
Ok, I did a new bug report specific to the topic: https://bugzilla.gnome.org/show_bug.cgi?id=753149
(In reply to psychoslave from comment #125) > Thank you for doing something. I'm not sure I get what you mean. Is that > consistent with Nautilus behavior? It will be if and when nautilus adopts the same idea. For now it is an innovation on the file chooser side only.
Ok, but what about simply integrate the already existing behavior? As I understand it, the trend was to: * focus this bug report on resolving its topic, which is, according to the first post, "a more consistent desktop [that] follow[…] Nautilus’ 'Single/Double click to activate' option"; * skip innovative works from this bug resolution; * contribute to innovative behavior in a broader bug report[1] which will be consistent across all GNOME projects. Is anything wrong with this plane? [1] https://bugzilla.gnome.org/show_bug.cgi?id=753149
You are going in circles. See comment 98
We all want a "good solution", in the file chooser as well as in nautilus. What will we call a good solution though? We probably need to define some quantifiable properties here, such as * how many time the user have to move the cursor * how many simultaneous input are needed * how many consecutive input are needed * how short must be the time between consecutive input to trigger an action (ie. double click) * how long must be an input to trigger an action (ie. long press) More properties could be evaluated, but would require a pool of testers such as: * discoverability (ctrl/shift + click is bad on this point for example) * accessibility (though special feature can be enabled, a default "work for everybody" solution is preferable) Now let's analyze the following solutions with this properties: * current file chooser/nautilus default behaviour * nautilus single click mode * comment #123 proposal * comment #128 proposal I'll come back with an analyse using this criteria as soon as I can.
Looks like this bug is gone for next seven year.
Just for the record, it seems like something happened in the 3.18 series where some hybrid approach was added, leading to bug #758065.
For me the most logical thing to do is to follow what have been selected in Nautilus (single click or double click).
(In reply to Jean-François Fortin Tam from comment #137) > Just for the record, it seems like something happened in the 3.18 series > where some hybrid approach was added, leading to bug #758065. That's what Matthias said was talking about in comment #123.
It's really unintuitive and lead to error or when you know the behaviour force you to be really careful about where you click. I really hope that will be fixed soon, ideally by following what have been selected in Nautilus (single click or double click). Thanks !
@jeremy9856: Please refrain from adding comments to a bug report when your comment does not offer any additional information (or is just the same as in bug 758065). Every comment creates notifications that someone has to read (who cannot write or fix code in that time), and advocacy is not welcome.
It seem that Daniel have found the culprit ! Can this commit be reverted please ? It will fix the problem. https://bugzilla.gnome.org/show_bug.cgi?id=758065#c19 https://git.gnome.org/browse/gtk%2B/commit/?id=fb0a13b7f070a14312dafa1e4df6ba03cf33be01 Thanks !
Jeremy, that commit is for a related but separate issue * single click opens an item that is already selected, and the first item in a newly entered folder is selected to this one * a request for a way to avoid double-clicking altogether. Please, only comment on the single bug that is actually relevant. Don't double-comment. We have enough confusion between single and double things already, right?
I've found this bug because I've set nautilus to single and file chooser isn't following this setting. I'd like to share some thoughts here if I may. I work in 3D software and I've been using single click since some really long time. For lots of folder clicking single click is a must because of hand fatigue. For me most problematic with single click is selection of multiple scattered around files. So: 1. Under KDE plasma there are "+" signs located on top left of icons. It seems to be unavailable inside file chooser and not-so-easy to click. 2. Under Windows 10 there is delay for selecting files. Delay is not adjustable and default is too long so eventually I click with ctrl. It also forces me to keep my cursor still as accidental mouse over can cause select despite of long delay. 3. Blender file chooser has it's own UI and there when you single click on folder it opens. But when you click on file it selects and open on double-click. It speeds up navigation (single) and prevent accidental file opening (double) but you have to adjust muscle memory. 4. GNOME doesn't use any selection accelerator and here I just use ctrl to select. It works fine. There is only one "corner" case: when you have one file selected and want to select another one to rename. You need to: - deselect with click on empty space - ctrl click new file - F2 to rename This could be solved enabling right-click shortcuts (F2, ctrl+c, etc.) when mouse is over icon. It would be consistent with window activation on mouse over option inside tweaks. Shortcuts work when window is activated so it's possible to do ctrl+c, ctrl+v just with moving mouse over between to text editors. It is one of this GNOME things I really like. Let's think out of the box. In my opinion most of accidental selection of files in file chooser lies in lack of mouse-over (it is second big difference between normal file list and file chooser list after lack of single click). I don't know if file below mouse cursor is or is not highlighted so I click to CHECK if it is. Mouse over gives kind of WARNING: "look, you will open THIS file (and e.g. send or attach) if you click". For me working with mouse is really different then working on touch screens and should not be connected at all. Mouse is aimed for speed, precision and features (lots of types of clicks and modifiers available) to get job done.
Mouse-over to select, as implemented by Windows, is horrible; it forces you to concentrate hard on exactly what you're doing with the mouse, otherwise files keep getting selected and deselected with no sense that you're in control of it. Please don't implement that.
That's what I'm talking about, I've mentioned Windows as bad example. Most important thing is to separate standard "mouse over" (GNOME) from "mouse over selection accelerator" (windows) Both my ideas ("shortcuts enabled on mouse over" and "mouse over in file chooser") enhance current solution and don't select files. First allow usage of shortcuts available in context menu *without* actually selecting file (single). Actually it is similar to copy/paste feature in Blender with mouse over: https://www.youtube.com/watch?v=IuGYwZX35u4 time: 9:17 Second informs user what file will be selected/run if he clicks. It's just simple mouse over inside file chooser.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/228.