After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688001 - Moving files to several different subfolders cumbersome after removal of tree view
Moving files to several different subfolders cumbersome after removal of tree...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Navigation
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-09 17:20 UTC by deduktionstheorem
Modified: 2013-07-24 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description deduktionstheorem 2012-11-09 17:20:31 UTC
Disclaimer: This is not a rant. I don't know where else to turn and it truly is a bug in my opinion.

With gnome 3.6, the tree view was removed from nautilus, *seriously* undermining its usability. I understand that you want to keep interfaces simple, but let me give you an every day example:

I download a couple of papers at work, placing all of them in the ~/downloads folder and then renaming them. So far, so good. Then I archive them, where they belong. But this is not in the same folder, it rather is in

~/documents/papers/linear_programming
~/documents/papers/computational_geometry
~/documents/papers/computational_geometry/art_gallery
~/documents/papers/other_category/subcategory1
~/documents/papers/other_category/subcategory2

Now prior to gnome 3.6 the workflow was to drag the first paper over the tree view on the left, opening up the subfolders as I need them, and finally dropping the paper where it belongs. This is *one* drag and drop operation, one click if you will. The other papers follow using the same pattern, only that they work even faster, because the used part of the tree already is expanded. In short: one click per paper.

How do I do that with gnome 3.6? I honestly don't know. I could open up one instance of nautilus (or one extra tab) per target path, leaving me with >5 tabs/windows open crowding my desktop and not really well-arranged. Besides it takes number_of_subfolders * depth_of_subfolders clicks >= 5*3= 15 clicks just to *prepare* these operations, not counting the actual drag and drop.

Another option: right-click on a document and select a path via 'copy to'. This takes even longer, because I have to select the entire path for every single document.

As I see it, this is a serious restriction in usability, because, to be honest, it is both easier and faster to just use a shell and the 'mv' command. I don't think I need to say that it is the death sentence of a user interface, if it is not any simpler or faster than a plain shell.

Maybe I just don't use nautilus correctly, but I fear I'm not alone with this experience [1][2][3] (just look for "tree" in all those links).

Please just reintroduce at least the option of turning on tree view again, both as side pane view and on the right "main panel". This really would make nautilus useful once more - because it is the only sane way to keep open several directories at once.

Best wishes,
Stephan

[1] http://www.zdnet.com/linux-mint-developers-work-on-gnome-file-manager-fork-7000002232/
[2] http://www.techrepublic.com/blog/opensource/gnome-is-simply-losing-its-grasp/3834
[3] http://worldofgnome.org/the-best-5-new-features-in-gnome-files-3-6/
Comment 1 André Klapper 2012-11-10 17:59:38 UTC
(Fallout of bug 676897)
Comment 2 mbooth 2012-12-13 22:42:30 UTC
As a daily user of tree view, this also gets my vote. The absence is jarring.
Comment 3 tuxor 2013-01-23 10:43:17 UTC
In bug 676897 Cosimo argued (comment 3), that "the tree sidebar is just a less-powerful list view". Afaik, the list view used to provide the possibility to expand folders in place (see http://people.gnome.org/~vnoel/screenshots/nautilus-treeview.png - this feature was implemented in 2005).

But since Nautilus 3.6 doesn't have this feature any more, I don't understand in how far one can call the tree sidebar a less-powerful list-view?

Are there any plans to reintroduce the feature of expandable folders in list view?
Comment 4 drtebi 2013-01-26 00:07:14 UTC
I completely agree with Stephan.

The tree view is an essential part of a file browser; as a matter of fact, it is one of the major reasons that the Mac OSX has never won me over.

Please bring it back.

DrTebi
Comment 5 Federico Tramarin 2013-02-04 10:38:08 UTC
I agree too...

What's wrong with the tree view?
Nautilus in the current version lacks of those couple of feature that brought it to be a very good file manager, say split pane and tree view!

Honestly I am completely aware that a powerful developer might not be touched by these problems, and a small and easy script on bash would easily solve the problem...but is this usability? Is this the right way to tell people that linux is no more so difficult to use?! And another one, if I have two minutes before leaving my office, do you find I have time to open the terminal, write ten to 20 commands on it, verify if I've done the right thing, or if you prefer, open 10 nautilus windows, starting a cut and paste operation with a number of windows on the screen, maybe pasting in the wrong one...

Wow, what usability improvement Cosimo and the other developer have been able to introduce!

Please, bring back both the tree view and the split pane!!!

Federico
Comment 6 Cosimo Cecchi 2013-02-13 00:47:10 UTC
For all the feedback we got on 3.6, and the fact that we need to accommodate the "classic" session in 3.8, we now have put the tree view back in git master, complete with in-place expansion of folders in DnD like it was before.

I think we can close this as FIXED.
Comment 7 Giuseppe Castagna 2013-03-24 12:31:01 UTC
Thanks a lot for having put it back, this was/is an essential feature to use nautilus and moving/copying files around (since it was removed I went back to dear old terminal line to move them). Just, do we have to wait for 3.8 to have it back or can we already have it in some 3.6.x? (I'm currently using 3.6.2) I clearly prefer the latter since I upgrade gnome version only when I upgrade the distribution and this is more than 3 months away.
Comment 8 André Klapper 2013-03-24 16:10:13 UTC
Stable upstream versions are under UI and feature freeze.
That doesn't stop you from asking your distribution to backport patches. :)
Comment 9 Giuseppe Castagna 2013-03-28 12:56:38 UTC
I'll do, thanks.