On Wed, 2010-06-23 at 13:04 +0100, Allan Day wrote: > Hi all, > > Garrett recently blogged about reworking parts of Nautilus's interface > [1]. These proposals are the result of a lot of work that him, Hylke, me > and others have been doing recently.
Unfortunately this is an epically bad time for me wrt nautilus work. I'm gonna be very busy with my work in spice over the summer, and then I go on parental leave from middle of september until about february. I won't have any significant time for nautilus until then. In fact, I hardly have time for even reading Garretts blog, much less thinking deeply about it. :/ In general I don't mind a simplification like this. For instance, i know we have a bunch of users for things like notes, backgrounds, custom icons/emblems, etc. But even so these are not core parts of file management, so I wouldn't really mind losing them if the benefits are good. And a drastically simplified UI *does* look good to me. However, there are a few things that I actually think are important to the core file management that are lost in your version: * Show the filesystem While I agree that navigating the filesystem from the root is not an extremely common operation, it *does* happen. So, while it should not have a significant visibility in the UI it should be accessible without using any hidden method or enabling any "uber-geek" mode (thats generally not known about unless you google for it). I know you think that "normal" people should not have to do this, but I think your definition of "normal" is a bit to tight. Nautilus is the main file manager of the desktop, and the desktop should let you do everything you need without falling back to the terminal or other "hidden" means, for *all* users. Let me list a few reasons to navigate outside your homedir: * You set up a shared directory outside your homedir for e.g. music files or movies on a machine with multiple users * At the office everyone has various nfs automounts that contain shared project folders for all the projects the company has * You want to get a file with another user that is in his homedir * You're a system administrator (and you'd like to only read things with raised permissions when its really really necessary, for security reasons) * You're a developer and use nautilus-svn or equivalent, and your source trees are not in $home * You need to find and attach some logfile to a bugreport * You have a webserver serving from /srv/foobar, and you want to manage files there * You're a student on a course and are told that the files needed for the assignment you're working on can be found in directory "foo" somewhere. * ... many other Now, some of these could be done in better ways, the file sharing for instance, but sometimes file sharing is just not set up right and you just need to do it this ways. Many others could be handled with bookmarks, but that only works if bookmarks are already set up, and initially they are not (and additionally there may be way to many projects to have them all as bookmarks so you're more likely to only bookmark the ones you're currently working on). We should do our best to make all these cases have better ways to do them, but at the end of the day there will be cases and setups we didn't think of, and the file manager needs to be generic enough that it can handle them anyway. And it needs to do this for everyone, not just "uber geeks" that know how to enable some magic knob, because you can never tell when any user suddenly needs to do something not supported by another approach. * Tree sidebar While I think the places sidebar is a better default for most people I still see a great many people using the tree sidebar. If you know your way about a filesystem and need to manage large hierarchies with many files this is a very good way to get an overview of things and navigate efficiently. Having this availabile is just a drop down menu on the sidebar title, so its very low profile for people not using it. I can't see it being a significant confusion creater, it doesn't use more UI space (it shares space with the places sidebar) and its very powerful for the people that want to use it. * Split view I know you designers claim this is useless and make pointless jokes about "extra pain", but there is a reason why dual pane file managers has been around forever and why many people like them. And its not the same as placing two windows next to each other, so a better WM is not the solution here. Having two windows next to each other duplicates all the window chrome, which is kinda painful, but it also loses the main advantage of split views, which is that the file manager knows about the connection between the two views, so that you can very efficiently do options like "copy to other location", or have tools like compare-two-directories. And keyboard navigation is *much* better inside a window than with two windows. Of course, split view is not something everyone will use, and even the people who use it won't use it all the time. So, it has to be made as "small" as possible in the UI when its not active. But I think we've done a pretty good job at that. Its basically just a single menu item. * Select view type I don't see how you switch between e.g. list view and icon view in your UI. I'm not sure I like the new context menu replacement. The way its shown horizontally means that there is very little space for items, if you don't want to require a large window size. Basically it means that you have to hand-design the context menu such that the longest translated strings in any language fits in some smallest window width we decide on. But that is not how context menu items work. They vary greatly with different types of files (this is the context sensitive part) and they are extended by things like plugins and script to make them even longer. This extensibility would essentially be impossible with a limited screen space for the context menu like in the proposal, removing the possibility to extend nautilus for user specific things like version control handling, custom scripts etc. One thing I've long had on my todo list for nautilus but so far have not had time to implement is a preview pane. This wold be something you can enable and would show a larger preview of the current file, including metadata for it and a button to e.g. play a movie or a music file inline. Somewhat like this: http://njpatel.blogspot.com/2007/02/nautilus-metadata-love-at-first-sight.html It would be nice if the new design had a place for something like this. (This would also replace the hover-over play of mp3 files which can be something of a pain if you accidentally trigger). Oh, and a last note, nautilus *does* have saved searches (i saw on irc that you didn't know this). Just do a search and then "File -> Save search As...". Its not super visible because its kinda useless without a working indexer setup and there has long been performance issues etc with tracker and beagle such that most people don't have it enabled. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's an obese sweet-toothed romance novelist trapped in a world he never made. She's a manipulative streetsmart vampire from out of town. They fight crime! -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list