GNOME Bugzilla – Bug 96239
Multi-column list view (aka Miller Columns)
Last modified: 2017-01-04 09:12:18 UTC
It would be *really* cool if nautilus had columned list view support like Mac Finder or Tkdesk. Right now, nautilus lacks overview because of rather poor tree view support (sorry, but this just doesn't work well), whereas with columns you have a really clear overview and file management operations are so much easier. For example if you need to move a file a directory a level up this is a pain in nautilus, ofcourse you could use cut/copy/paste but this is really confusing (cut? huh, but the file is still there?), whereas if you have columns it's just a matter of DnD. This would introduce a problem though, views would be rather confusing. Well, personally I dislike views anyway - weird UI mixed with nautilus UI, buggy, slow, you lose your directory view, etc. I think quick and small external viewers rule, because they don't have any of the problems - this works really really well on Mac. (Another plus of tkdesk and finder is that it has a configurable toolbar, which allows for *really* useful things like "new directory" and "open terminal here" buttons.) If you don't want nautilus to take this direction, I'll have to write an fm myself since tkdesk bitrots more every day :)
I don't understand what you mean by "columned list view". Could you explain in more detail what it is and how it operates for those of us who haven't used Mac Finder or Tkdesk?
attaching a shot. When you click on a folder in columned mode, it opens that folder in a new column. If the columns dont fit in the screen anymore, a scrollbar is created (see the left-bottom window). If you click in a dir in one of the first columns, the next column after it opens in the requested dir - any columns afer it are destroyed. The statusbar shows the info for the last column. Also it is really easy to switch between the three view modes; icons, list, and columned (the three buttons in the toolbar). As you can see, "Image Capture" has been added to the toolbar - this is done by just dnding the app to the toolbar. It would be really cool to have this in nautilus, since you could have things like "open image viewer here" or "open terminal" there.
Created attachment 11688 [details] screenshot
jorn this would rule, you offering to implement this? (hint hint wink wink...) Also I should add that the hig (cvs head) mentions this type of view as a replacement for complex tree views. Also a macos style list/tree view would be really cool.
I don't think I'll have time to do it myself, but who knows.
This looks like a duplicate of bug 81610. Although since this bug has more information, maybe someone should mark it a duplicate of this.
*** Bug 66768 has been marked as a duplicate of this bug. ***
It's good, but it should be tied to the browser mode since it is useless in spatial. In that way the column view option is available (or automatically set) when you browse a folder in navigational mode and is replaced by the icon view if you browse the same (or other) folder in spatial mode.
I don't have time to work on it too, but I think it would be usefull. Here are some links to Open Source projects of file manager which implement column view yet : Evidence (Enlightenment) : * website : http://evidence.sourceforge.net/ * code : http://sourceforge.net/project/showfiles.php?group_id=58061 EFM (Enlightenment) : * website : http://www3.get-e.org/E17_User_Guide/English/_pages/3.10.html * code : (not found) Thunar (Xfce) [only on a branch]: * website : http://thunar.xfce.org/index.html * code : http://thunar.xfce.org/wiki/ui:columns-view GWorkspace (GNUStep) : * website : http://www.gnustep.it/enrico/gworkspace/ * code : http://www.gnustep.it/enrico/gworkspace/#Download I hope it could be helpfull.
Hello, I would really like to have this column view in the default File Manager of Gnome. In fact, I also use a Mac and I always use the column view there. You should also add the possibility to disable the preview when clicking on an item that is not a folder. In fact, on the Mac, I keep the preview most of the time disabled, because some files (especially some long videos) take to much time to create the preview and the File Manager (=Finder) remains unresponsive until the preview appears. Finally, thanks to Fabrice for the list of File Manager with a column view like that of the Finder. Francesco
I've started to implement a column view. Most things are working but i need to clean some things up. Hopefully i'll have a patch mostly ready by the end of the week.
@Trevor These are good news; thanks. :)
How do we know when the patch is ready? Moreover, how can we test it? Is this the right way? - download the source of nautilus - download the patch - patch the source code - compile the source code on the linux computer (ubuntu feisty to be precise) where I want to test it? If it is the right way, could you please tell me where I can find the sources of nautilus and the patch? (I have already compiled several programs from source, but never patched one; I hope I will have have to many problems.) Have a nice day. Francesco
I got really busy at the end of the week so didn't get quite as much done as i wanted. I mostly just need to finish the zoom support (it's mostly done) and then drag'n'drop which is barely started but should be quite straight forward. I hope to have a patch sent the list by the end of the week so that review can start so I can be sure that all issues (cause i'm sure there will be lots of things I missed) are resolved before the next freeze (whenever that is). I work off of whatever is current in svn. For help with that see http://developer.gnome.org/tools/svn.html
Hello Trevor, Thanks for your reply and especially for the link. Will you post the patch for the columned view to this thread when you have it ready? By the way, regarding drag and drop (dnd): the dnd behaviour in Nautilus (and generally in GNOME) does not work as expected: when a dnd begins, the window that contains the item to drag, raises to the front and potentially covers the target region. The raising should not happen and this behaviour has already been filed as a bug several years ago: http://bugzilla.gnome.org/show_bug.cgi?id=80984 Thanks again for doing the column view development.
*** Bug 499380 has been marked as a duplicate of this bug. ***
For future reference, and to add keywords to help people find this bug, the actual feature here is called a Miller Column Browser: http://en.wikipedia.org/wiki/Miller_Columns The main advantages for me are that it's easier to keep track of where I am in the hierarchy than Tree view, and it's easier to navigate with the keyboard (plus, the last column tends to show information about the currently highlighted item, so less mucking around with the Properties window)
Column View (Miller Columns) are mentioned as a target for GNOME 2.24 in the current drawing of the release notes of GNOME 2.22.
i was hoping for column view in 2.24 to be miller columns aswell, but i'm afraid what is meant is the new compact view. could anyone clear this up please?
This feature is implemented in Dolphin, in KDE 4 : * website : http://dolphin.kde.org/ * code : http://websvn.kde.org/trunk/KDE/kdebase/apps/dolphin/src/ I hope it could be helpful.
Could anybody clear us up whether column view scheduled for GNOME 2.24 are Miller Columns? I am wondering whether Björn is right about it being the compact view? By the way, I just installed Dolphin by using the Synaptic Package Manager in the development version of Ubuntu 8.10 and I can confirm that it offers Miller View.
They are not Miller Columns: http://blogs.gnome.org/cneumair/2008/02/17/new-column-wise-nautilus-view-user-data-backup-replay/
I am using gnome 2.24.1 now; I can confirm that Miller Columns have not been added. In searching for discussion related to this feature, I found an interesting back and forth on the nautilus mailing list: http://osdir.com/ml/gnome.nautilus/2003-12/msg00000.html A number of the Nautilus developers seemed actively opposed to the idea. I find this unfortunate, since I find the "Compact View" feature, which emulates Windows 95 and Mac OS System 6, to be less useful than Miller Columns, although, to be fair, I imagine it was easier to implement.
"There are no plans to implement a column view in 2.6." is not opposing an idea. In fact, several people have expressed interest in working on a column view, but no working code currently exist.
In other words: if there is somebody implementing miller columns for nautilus, the corresponding code will be accepted. Correct? What are your requirements about maintaining the miller columns once they have been integrated to nautilus? What about possible patent issues? Are the spring loaded folders not patented? If so, they can't be used exactly as in the Finder of Mac OS X. (For example when dragging a file into a subfolder on another volume, spring folders are quite useful. but as nautilus already offers tabs, at least this problem can be solved by opening the destination folder in a second tab before starting the drag. In fact, that is how I am already doing it, only that I navigate the folders in Detailed view as miller columns are not available; I don't like tree view because it involves to much vertical scrolling.) I am trying to get an overview of the scope, for the case there are some developers ready to implement miller columns.
Something like what GNUstep does would be peachy keen. It's kind of like "list" mode, but with nested columns. Here's a jpeg image of the GNUstep implementation: http://en.wikipedia.org/wiki/File:GNUstep-liveCD.png I agree, spring-loaded folders are pretty cool, although spring-loaded folders are a feature of OS X's "icon" mode of folder listing, rather than the (Miller) "column" mode. I don't know what the patent restrictions on OS X's spring-loaded folders might be, but I wouldn't be surprised if they were rather strict.
(In reply to comment #25) > In other words: if there is somebody implementing miller columns for nautilus, > the corresponding code will be accepted. Correct? Yes, AFAIK. Please also realize that both using NEEDINFO against developers is wrong and that setting an *enhancement* request to Severity=Critical and Priority=High will not make this report ramp up the developers' TODO list, but is likely to piss off someone, thanks.
Hello, > Please also realize that both using NEEDINFO against developers is wrong and > that setting an *enhancement* request to Severity=Critical and Priority=High > will not make this report ramp up the developers' TODO list, but is likely to > piss off someone, thanks. I hope that nobody got me wrong: the main purpose of my post in comment #25 was to clearify the acceptance of the Miller Columns for the case that there would be somebody, that is not already a nautilus maintainer, with the intention to implementing it. In fact, the link in message #23 was causing doubts about it. It is clear to me that often the maintainers of packages already have a lot of work; that is why I also touched the topic of maintaining the miller columns once they would have been implemeted. Ok, this might have been a bit premature... Again, I only tried to be constructive; there was no intention from my part to put any pressure on the developers of nautilus to implement miller columns. Sorry for the misunderstanding, if my comment #25 was not completely clear.
I understand your intentions, sorry for my previous harsh comment. What I mean is: - NEEDINFO+critical+High bug status is *definitely* not the right way to ask these question to a developer. IRC, mail (either private or to the list) work better. - without some code written by someone, it's difficult to know who will take care of this still-non-existent code :) - public bug reports are there so that anyone can contribute by writing a patch for the bug/feature. Let's stop this discussion here, and wait for some code instead :)
*** Bug 610528 has been marked as a duplicate of this bug. ***
Renaming and changing component for clarity.
I created bug 635488 (implement Miller columns in gtk+) because Miller columns are useful enough that they should be generally available (rather than restricted to nautilus).
Created attachment 179404 [details] Dolphin Columns for better understanding one more screenshot from the KDE filebrowser Dolphin
Created attachment 181247 [details] experimental miller-column widget Hi, what is the current development status of Miller columns? I have hacked-up a miller-column-like widget (see attachment) and I'd like to know if anyone is already working on this. Basically, what I've done is creating a list of GtkHPaned, each paned packed as the second child of its parent, the first child being available for embedding other Gtk widgets. Resizing is implemented in such a way that all the columns have the same width. It is still very experimental and far from being useful, it's just a sort of proof of principle! A possible way to use it is to pack a GtkTreeView in each miller column, all the treeviews sharing the same GtkTreeModel, but maybe this is not the optimal solution. A better way is perhaps to subclass GtkTreeView itself. Anyway, I'd really like to see Miller columns in Nautilus, so any feedback is greatly welcome!
Hey Stefano, Thanks for your work on this. The first thing we need is a decision about whether Miller columns would make sense for Nautilus. A few remarks here: In general, I really like Miller columns. They are an excellent way of navigating and moving stuff around a file system. That said, I have a couple of concerns about their appropriateness for Nautilus: First, Miller columns would overlap with the functionality provided by the breadcrumb. Nautilus is focused around this. There are some ideas for how it could be extended [1] which might further make it overlap with Miller columns and which might even make Miller columns redundant. A focused UI is definitely a good thing in my book: having overlapping functionality can be confusing and generally lacks elegance. Second, I'm not sure whether we want to be extending Nautilus's views. Having multiple modes which must be manually switched by a user seems to go against the goal of making something that Just Works. We might do better to focus on improving the default view and functionality in order to make it suitable for as many use-cases as possible. Don't get me wrong - I'm not dead against the idea of Miller columns in Nautilus. I just think we need weigh up the options. [1] http://live.gnome.org/Design/Breadcrumb
> whether Miller columns would make sense for Nautilus. That seems like asking whether scroll wheels make sense for mice. > In general, I really like Miller columns. They are an excellent way of navigating and moving stuff around a file system. Indeed! :} > might even make Miller columns redundant Every different view mode is fundamentally redundant, and useful for its differences. > elegance As the software in question is a tool (rather than jewellery) utility and capability are more important that elegance (and they need not diminish it anyway). > confusing ... something that Just Works The de facto standard for nonconfusing-elegant-JustWorks implementation is OS X. Even the iPod uses Miller Columns, because it works. Apple used to think that mice only needed one button. It's true that additional controls are redundant, possibly confusing, and arguably less elegant but they sure are useful, and they certainly get used. > to make it suitable for as many use-cases as possible. That seems a good argument to *include* Miller Columns (not avoid them). Regardless of what happens with Nautilus, GTK+ should include Miller Columns (see bug 635488).
Created attachment 181371 [details] animated column view mockup Hi Allan, > First, Miller columns would overlap with the functionality provided by the > breadcrumb. Nautilus is focused around this. There are some ideas for how it > could be extended [1] which might further make it overlap with Miller columns > and which might even make Miller columns redundant. I wasnt't aware that there were plans to extend the breadcrumb. The Crumb menus seem indeed a good replacement of Miller Columns, at least to some extent. Something gets lost anyway, namely the ability to grasp the directory tree in a single view, but the critical problem of moving files around with ease seems solved. > Second, I'm not sure whether we want to be extending Nautilus's views. Having > multiple modes which must be manually switched by a user seems to go against > the goal of making something that Just Works. Ok, I'm perfectly agreeable about this point. So, instead of considering Miller columns like a different view we could consider it as an "overview" mode, like the gnome-shell: switching to this "overview" the user has the chance to see all the directory tree and move files around. Animations can be used to make clear to newbies what is happening (see attachment). If you don't like the "overview" metaphor, it can simply be called "persistent" Crumb menus, or something of the kind. The implementation can rely on Clutter, I think, (which is anyway already pulled in memory by gnome-shell) so it shouldn't be a huge problem. Surely it will involve a lot of work, I understand this, but maybe it will be the occasion to finally integrate into nautilus this feature which, as recalled by dicktyt in post 36, has proved itself to be useful, intuitive and "just working" in a lot of use-cases!. Cheers Stefano
And annother 3years passed without anything -.- Thats really not funny anymore =( Even worse, Status:NEW - not even confirmed after 8 years 4 months. Even wikipedia cites this already "still discusses the necessity of Miller columns while numerous users demand it" Why on earth should it not be implemented? OSX is using it for years, simply because it works and its highly efficient. And they spend the most $$$$ to analyse what is easy+efficient, why not just copy it 1:1? Or make your own studies and you will recieve the same result... And the breadcrumb is not that masterstroke of efficiency, but ok ^^ If you measure the efficiency based on what feels efficient ("needed clicks" , "millimeters of mouse path" and "time needed") to perform different file actions, right, just go for miller columns :-) So please, please have some mercy with "the numerous users who demand it" and make us all a very very nice present with ribbon for easter and implement it even if you dont find it that genial as we all do. And for any question about "how" - just copy the behaviour from osx, they put already humongous hours inside that exactly navigation on various different end systems and gilded it. Thank you =)
(In reply to comment #38) > And annother 3years passed without anything -.- Thats really not funny anymore > =( > Even worse, Status:NEW - not even confirmed after 8 years 4 months. > Even wikipedia cites this already "still discusses the necessity of Miller > columns while numerous users demand it" > > Why on earth should it not be implemented? Because you didn't implement it? This is bugzilla, not a way to contact developers to get them to work on whatever interests you. <snip> > Thank you =) Yeah, that makes it all better...
I'm pretty sure that this isn't something we want. The aim is to keep the number of views at two - one for list and one for grid - in the interests of simplicity and ease of maintenance.
That would be a terrible shame. column view is an *incredible* productivity booster. macOS has had it for 16 years and it doesn't seem to have resulted in unmaintainable code or confused users there. This is a *really* common feature request.
(In reply to Nate Graham from comment #41) > That would be a terrible shame. column view is an *incredible* productivity > booster. macOS has had it for 16 years And NeXTStep for another 10 before that. > and it doesn't seem to have resulted > in unmaintainable code or confused users there. How would you know? :) > This is a *really* common > feature request. And apart from one attempt 5 years ago, nobody came out with a patch. Until somebody does and can show it's better, I doubt leaving this bug opened would result in any more development activity.
Worth mentioning in case you want to test it in a file manager similar to Nautilus, the elementary OS file manager has it together with icon view and list view. I have no strong opinion on this after trying it.