GNOME Bugzilla – Bug 138931
allow multiple selections with mouse (and single click)
Last modified: 2021-06-18 15:56:16 UTC
Currently there is no way to select multiple files with just the mouse in list view. Clicking and dragging over any part of a line with a file on it starts DND and trying to start from an empty area does nothing. I believe that list view would be more useful if only the filename and icon counted for selection. Is this possible?
*** Bug 110291 has been marked as a duplicate of this bug. ***
Confirming. Should be possible, but it's hard to implement with the current design, since the list view is based on a gtk_tree_view (which doesn't support rubberband selection).
i agree i would love to be able to do this in the future.
*** Bug 164632 has been marked as a duplicate of this bug. ***
gtk 2.10 provides rubberbanding in the treeview. Does this API ssems enough to support it in Nautilus? It would really makes the selection easier :)
Martin Wehner, I just installed Thunar, XFCE's file manager, and I noticed that it allows lassoing the contents in the list view. You could take a look at their code maybe?
Thanks for the hint Jeff, we finally have rubber banding support in GTK+. I filed bug 80127 since there is no way to query whether rubberbanding is done ATM, which would allow us to add rubber banding support to single-click mode. As of writing, rubberbanding is only possible in double-click mode.
Sorry, wrong bug reference. I filed bug 393579 and it turns out that without this API we can't properly decide when to drag and when not, both in single and in double-click mode. Sorry guys, but this means we'll have to delay this one again :(. Updating priority and version, milestoning to future as we'll have to depend on GTK+ 2.12.
Created attachment 95539 [details] [review] Proposed patch
some suggestion about the rubberbanding behavior (as already work on most fm on earth): d'n'd a folder on other one -> move rubberbanding on filenames -> selection rubberbanding + ᐱ + rubberbanding -> non-contiguos selection
Created attachment 97766 [details] [review] select files by drag mouse with left pressed At present, if we move mouse with left pressed, the selected file will be dragged. The patch makes a little difference: if we left press the mouse at the file-name column, it will effect as before. if we left press the mouse at the blank space or at other columns, it will begin to select all the rows it moved over.
*** Bug 506846 has been marked as a duplicate of this bug. ***
*** Bug 375469 has been marked as a duplicate of this bug. ***
Christian, you made all the wonderful work with the Gtk API addition and the actual patch to handle rubberbanding. Is there something still blocking commiting and closing the issue? With this one and the column view you'll have closed the two major ppl complains ;)
Any news on this?
Manny: ping
> Manny: ping GTK+ does not allow to treat any regions of rows as background, although that would be required for smooth interaction. See http://mail.gnome.org/archives/gtk-devel-list/2008-April/msg00036.html for a discussion and two implementation proposals.
Created attachment 120435 [details] [review] Prelimitary patch The attached patch enables rubber banding. It also ensures that everything except the non-empty parts of the file column are treated as background. This is required to distinguish between rubber-banding and drag and drop interaction. Unfortunately, the user experience is a bit inconsistent because the GtkTreeView rubberbanding support is not aware of this cell background concept - the entire row is treated as selectable foreground, for instance when left-clicking. I have tried out various ways to work around this issue, but none succeeded. Maybe it's best to add a supplementary patch to GtkTreeView which also adds the following concepts * allow to only treat cell renderers as foreground (based on event_hit_test() in my patch) * allow to constrain the foreground interaction to a distinct column * possibly modify highlighting to make the foreground range more prominent Another issue is that the dead space on the bottom of the list can not be used to start a drag, which also seems to be unintuitive. Also note that we can not implement our own rubber banding support for now -- IIRC from hacking on DND highlighting it is impossible to get scroll interaction right. However, for the brave of you this is at least a nice sneak preview patch.
*** Bug 566484 has been marked as a duplicate of this bug. ***
I think it will cause trouble for users if some parts of the filename is click-through while others are not. What is the rationale for this behaviour? It will probably seem almost random whether you can drag a row or not, if you don't know the implementation details, which no regular users do. I had filed a bug that was just marked duplicate of this one, but this is not the behaviour I am proposing in that bug. Instead, I'd just like to see the ability to start a rubber band selection from an empty part of the list view, i.e. below the list of items.
It's not enough to be able to start the selection from the empty part, since it's quite common that there is no empty space... I've tried the patch above, and it's promising :) I've been looking forward to this for a looooong time, and any progress is making me smile.
*** Bug 563116 has been marked as a duplicate of this bug. ***
Will this ever be implemented in List View? Any news about the current status?
Hey there, I have noticed that the current development version of GTK+ (2.17.6) has this feature. All the filechooser windows have working lasso in listview by default (and it seems to work quite well). However, Nautilus does not use that feature even when using gtk 2.17.6. Hope this info helps.
Still not implemented in Nautilus 2.28.1 (Ubuntu 9.10). Is there someone working on this ?
No. Updated patches welcome.
I've been discussing this with Calum today. He points out that OS X doesn't have a rubber banding in list view. Instead 'you can also use the white space to start a contiguous selection with the mouse, provided you don't start with a file that's already selected'. This approach makes sense to me. Rubber banding might not be appropriate in list view at all.
(In reply to comment #27) > I've been discussing this with Calum today. He points out that OS X doesn't > have a rubber banding in list view. Instead 'you can also use the white space > to start a contiguous selection with the mouse, provided you don't start with a > file that's already selected'. > > This approach makes sense to me. Rubber banding might not be appropriate in > list view at all. Dude, either way, it's unbelievable we can't select multiple files using the mouse in list view. I really don't care about Apple interfaces. I need a functional one.
+1 for `dierre.' Still no news?
Renaming for clarity.
One more for 'dierre'. I can't care less about Apple interfaces and Apple products. I will never buy their products. I also need a functional interface, and to me, this is currently Ubuntu's achilles' heel, due to the fact that most used distro is sporting Nautilus as default file manager. We see this working in Thunar and Brasero. Although not quite like Windows Explorer, which would be definitely the ideal thought, they do work but I am not going through the hassle to replace Nautilus for Thunar. I have thousands of files, FLAC collections, and every now and then I need to move them around and sort them out. It's hell through Nautilus without this feature.
General note: Please do not add "me too" or +1 comments as they do not add any value to this report. Bugzilla is not a forum. If you want to help, dive into the code and provide patches. Thanks for your understanding!
*** Bug 606714 has been marked as a duplicate of this bug. ***
*** Bug 312769 has been marked as a duplicate of this bug. ***
*** Bug 703300 has been marked as a duplicate of this bug. ***
*** Bug 723064 has been marked as a duplicate of this bug. ***
*** Bug 730474 has been marked as a duplicate of this bug. ***
*** Bug 730112 has been marked as a duplicate of this bug. ***
Comment on attachment 120435 [details] [review] Prelimitary patch src/file-manager/fm-list-view.c does not exist anymore in git master. Hence setting 'needs-rework' as patch does not apply cleanly against git master.
Wow this bug has been open 12 years ago ! I hope that a kind Nautilus developer will have interest in this feature and implement it. It's a really trivial feature but really useful and improve a lot the usability.
(In general, please avoid creating "I want this too" comments as they only create email notifications but don't help resolving the bug. Technical comments + contributed patches are very welcome of course! Thanks for your understanding.)
Hello please is there any progress on implementing this functionality? When using a wacom graphic pen for working in nautilus this functionality greatly is missing from a one-hand workflow. Having to reach to the shift/ctrl key every time one wants to select multiple rows(in list view) is not ideal, especially when switching over to nautilus daily from other file managers where this is implemented. example from finder: https://www.dropbox.com/s/8yomcqwhfsoqz10/selection-finder-onehand.mov?dl=0 Thank you for bringing new features to Nautilus!
If there was progress it would be noted in a comment of a bug report. :)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.