Re: Nautilus toolbar simplification

[Michael Toomim <toomim ocf berkeley edu>]

Jens Knutson wrote:
> On Mon, 2003-03-10 at 13:55, Michael Toomim wrote:
>
> >   o As for "Stop" -- why would you ever want nautilus to freeze in the
> >     middle of displaying a directory?  Or any other type of file?  I
> >     think that this button is rarely useful.
> I'm not sure this can go safely.  What about remote file systems?  SMB,
> NFS, FTP, WebDAV - all of these could use a stop button about as much as
Even with remote file-systems -- why would you ever want nautilus to 
freeze after drawing half a directory?  I can't imagine any scenario 
where I would want nautilus to stop-- and do nothing.  If the user 
hasn't clicked the back button (or given nautilus any other command to 
execute) there generally can't be any harm done in drawing the rest of a 
location.
In any case, I don't think that the stop button is used frequently 
enough in day-to-day file-management tasks to warrant a toolbar button. 
  When you're browsing directories and files you generally don't want 
to suddenly tell nautilus to "stop and do nothing".  And the feature is 
always available via the "escape" key and the menus if you do.
> The user's home is available in many places, yes, but toolbar inclusion
> is decided by how frequently a function is used by most users, according
> to the HIG anyhow.  While having it in those other places is nice, I'd
> guess it's popular enough that it deserves a toolbar button, too.
I disagree here, too.  Because the home folder is always within the 
user's immediate reach (even if there aren't any other nautilus windows 
open), I don't see the point of allocating toolbar space for it in each 
opened nautilus window.  It's true that toolbars should get 
frequently-accessed features, but what's the point of using the toolbar 
for a feature that's just as easily accessible from a slew of existing 
locations?
> >   o "Reload" shouldn't be needed if FAM et. al. is doing its job, right?
> >     And if it IS needed, you have View->Reload and Ctrl-R.
> See my argument about the stop button.
Even with remote filesystems, "reload" just isn't something that you 
have to do often enough to warrant a toolbar button.
I'm not saying that reload, stop, and home aren't useful features under 
some circumstances -- just that they're not used enough to be put on the 
toolbar.  I think that having a one-toolbar UI, with prominent placement 
for the *really* frequently-used features (back/up, location, view type) 
is a very important goal.  If you include buttons for all of the 
"can-be-used-in-some-situations" features, you can't achieve that goal. 
 So let's put the key, ubiquitous commands on the toolbar, and the rest 
in the menus and on the keyboard.
> In your mockup, you also ditch the spinner, which also must stay, for
> slower machines, for huge directories, and again, remote filesystems.
Yeah, I was wondering if anyone would notice that. :)  I've fixed the 
mockup now at the same URL 
(http://www.ocf.berkeley.edu/~toomim/redesigned_toolbar.png) and 
improved the back button while I was at it.
BTW, one of the reasons that you have to rely on the throbber is that 
there isn't any busy-interaction hourglass mouse cursor when nautilus is 
active (see http://bugzilla.gnome.org/show_bug.cgi?id=108041).
> That said, moving the zoom and "view as" controls up into the main
> toolbar and ditching the location bar in the default view aren't too bad
> an idea.
>
>  - jck