Re: The location bar in a OO UI

Hi Ryan:

Ryan Muldoon <rpmuldoon students wisc edu> said:

> Perhaps the answer is going to be some sort of ugly stepchild of an
> object oriented UI, especially in the near term.  An OO design would be
> pretty painful until we have things like spring-loaded folders, faster
> window construction times, etc.  While focusing on a paradigm is great,
> and can make things more consistent, we can't forget that the reason
> we're doing this all is to make people's lives easier (at least while
> they're using GNOME).  

Ryan I completely agree with your sentiment here. If we decide to pursue this 
paradigm of design, we are going to have approach it very slowly, adding new 
features (like spring loaded folders) that will be needed by it before batch 
removing others that conflict with it. It'll definately be a mutt for a 
while :)

> So a generic "open location" thing is a great
> idea, because that makes my life easier whether or not I'm using a
> navigational style UI or an OO ui.  It is supposed to work that way now,
> but it has a few bugs (like not handling spaces in filenames properly,
> etc).  Stuff like that *is* useful.  

Yeah i think this would be pretty cool in general and it provides a migration 
path as well.

> One trouble that I think is significant with OO file management is
> dealing with unusual locations.  Like remote locations, or hidden
> directories, etc.  It is more of a pain to open them.  

I think this can be addressed. First having a universal location bar will 
allow the user to easily open remote locations. Also a tree view (like the 
one in konqueror which I believe is consistent with OO design) can be used to 
address the issue of deep hierarchies.

> Also, a really cool concept that I'd like to see Nautilus incorporate is
> the EFM "command buffer" - where I can just start typing in a shell
> command that takes effect in the current directory.  Or a quick way of
> indicating a file filter (like *.jpg in my Pictures directory).  Does
> that even make sense in an OO file manager?  
>  .......
> There's a reason why google is so popular
> compared to portal sites - good searching is more important than being
> able to browse easily.)

Hmmm, I was thinking about this today, I think the sort of filtering you 
propose may make sense since you are basically acting on the current object, 
though i would like to think about it some more. However I think a better 
solution (less hidden to the general user) is to re-add search to nautilus 
via medusa and than have a toggle button on the toolbar to switch to search 
mode in which you can search for files in the current folder, which seems to 
accomplish the feature you would like and is consistent as you are doing an 
operation on the current object (this another one of those features i would 
like to see anyway).

> While considering the Nautilus UI, perhaps once we identify what the end
> goal is, we can look at what are solid intermediate points that make
> sense as end-user software.  Personally I'd like to see at least some
> notions of OO file management happen, but quite frankly, I'd be pleased
> if we just got things like spring-loaded folders, a bug-free run/open
> dialog, vfolders, and command buffers.  

I was actually thinking about making such a proposal. One simple idea would 
be moving the preferences dialog into the control center.

thanks for the input.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]