On Fri, 2009-02-20 at 16:08 +0100, Holger Berndt wrote: > On Fri, 20 Feb 2009 12:16:33 +0000 Alexander Larsson wrote: > > > If you > > even start Norton Commander chances are that you're gonna do some > > heavy file management, like restructuring a set of folders or > > something. > > Well, I don't know if people really switch file browser applications > depending on what they are about to do.. Typically, you choose one > tool, and then stick to it, as you have your bookmarks there and know > your way through the interface. > > I agree in so far as that default tool is likely to be Norton > Commander-like when heavy-duty filesystem work is a common task for > the user.
I understand what you mean and I agree that people don't use e.g. both mc and some other similar tool. However, that is not what I meant, and I think the issue is caused by applying the term "file manager" to things that are not quite the same. Let me explain by an example user. He is a terminal-only user, that likes to use mc (midnight commander). However, most of the time he's working on normal stuff is not spent in mc, it is spent in the shell, using "cd", "ls", "less", and starting programs with filenames (often using tab completion from cwd). Sometimes he just needs to copy/move a single file somewhere, so he uses cp and mv a bit too. However, when he's gonna do a large amount of copying, moving around, renaming, or restructuring he starts mc, because that is a more efficient way to do this. So, there are two kinds of uses here. One is the ordinary shell navigation stuff, and the other one is "file management". Now, nautilus sort of has the label "file manager", but it is really more of a graphical shell (thus the pun with the name). In other words, its the non-shell-users version of ls, cd, and command launching, with support of some other things like cp, mv, etc. I don't think even most mc users spend the majority of their time in mc, that is just not a good interface for normal work. In much the same way we don't want to turn nautilus into something that is mainly for heavy file management, because if we do we *remove* the only shell-like thing which is where most people spend most of their time. I think this is also a general source of much of the negative comments nautilus gets. I.E. people who use the terminal for normal use and think that Nautilus is a good app to use when they want to stray from the "normal shell use" and do heavy file management similarly to mc. > > However, what I fear is that introduction of a > > split view will lead to more and more creaping of the application > > model towards the norton commander style of application. > > That is true. As a matter of fact, there's at least one more feature > building on split-view that I'd personally like very much: > Meld-integration to diff the directories or selected files of the two > panes. This is the slippery slope in action. For each feature like this you add you get another user that "just" wants his favourite mc operation. Arguing against each single change is hard, after all its just one menu entry. However, that total end result is that you shift the style of the application. > > Also, I don't like the "Side Pane" toplevel menu. Menu operations > > should be arranged by what they do, not what application feature > > enable them. So, file copy operations should be in edit just like > > other such operations > > > > Generally we don't hide menu items that are not availible atm, we just > > make them insensitive > > Now, this is indeed a dilemma. On the one hand I completely understand > your reasoning. On the other hand, all this "extra" functionality > should not bother the non-split-view user at all, and I don't think > insensitive split-view menu items sprinkled all over the place are > a good idea. As a non-user, I'd be annoyed. > > Maybe it can be seen as a different "mode". We have spatial mode, we > have navigation mode, and this could be an "extended" navigation mode > that can be toggled on and off on the fly. In my mind this is the only sane approach to something like split view. A nc-style application model is just fundamentally different from a browser/viewer style application. The basic concepts is that you specify two arguments in the UI, which is what makes this more powerful than just two browser windows next to each other. However, this affects how you implement almost all file operations, for instance copy goes from dnd/cut-n-paste to copy-to-the-selected-destination. So, you'd have to duplicate the operations and then you'd end up with twice the number of operations and half of them are useless and confusing in the split view case. And the split view ones are either useless in the non-split view case, or you hide them and make the "split view" toggle unexpectedly also change a lot of the menu structures, etc. At the core of good application design is to do one thing, and do it well. This is for instance why the spatial mode was completely separated from the browser mode in the UI, so that each could be the best they can at how they are used. We didn't just add "open in a new window" to the standard browser window, nor did the requirements for little screen estate use in spatial windows affect how we designed browser windows. So, if we were to have a split view feature in nautilus it should really be a completely different kind of window/app in the eyes of the user. One designed to have all the advantages of a mc style app and none of the non-useful leftovers from the browser/spatial window. In other words, a nc clone based on the nautilus codebase, sharing code and user data (like bookmarks, mounts, emblems, metadata and history). I also agree with Rui Tiago Cação Matos that in the grand scheme of computer UI progress the more interesting approach is not to create tools that let the user do the frustrating manual crapwork managing files more efficient, but rather try to move away from having to do manual file management at all. This would rather lead to a focus on better previewing, better search, better tagging/metadata and automatic file mangement/structuring. Of course, this is a more experimental area with less known solutions, and the fact is that some people will still need to do manual file management for the forseeable future. How would a nautilus-based "mc clone" look? How would it integrate with the rest of nautilus (browser and spatial)? What names would we use for it? Would it be confusing for users with both browser and dual pane windows? These are interesting questions, and they need thinking and research. It might be interesting to look a bit in more detail how other file managers with an optional split view work and look. Things like konqueror, dolphin, etc. > > as otherwise the menus change in weird ways > > depending on app state, which causes for instance other operations to > > move in the menus. See the Gnome HIG for details. > > Maybe I got this wrong, but this should not be a real problem when the > menus hook into proper UI-manager placeholders. Only if the added items are at the end of existing menus, otherwise everything below an addition moves down. There are other reasons why this is bad too, see the HIG, -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
