Re: [Usability] The eternal fileselector dilemma :)

[Lemmit Kaplinski <lemmit kaplinski com>]

Hi,

Alan Horkan wrote:

> It is a little annoying when people post external links and dont include
> at least a preface or outline of their suggestions inline as it makes it
> much more awkward to respond to the points raised.
>  
Sorry :)

> The way I see this working would be that Save In Folder would become much
> more like the Bookmarks in Mozilla (call it Shortcuts/Locations if you
> prefer)
>  
This much we definitely agree on. The question is - I am not very 
familiar with how the Gnome project works and I can do zero coding. How 
should I go on about trying to push this idea and get it done. Does it 
have something to do with writing a GOP/GEP/GIP(?!).

> The Sidebar could be removed entirely, or collapsed by default with a
> grippy provided for users to expand it if they want (similarly the stock
> dialog could/should include standard preview widget hidden by default with
> a grippy to expand it as well, application could have it expanded by
> default if they really wanted).
>  
I am against duplication. There are many other things that need that 
space as bad. But if it must be there, the possibility to hide will come 
in handy.

> Breadcrumbs.
> Interesting idea but it I dont think it is anything special.
> I'd much prefer to have the Location bar back (and perhaps a small "Up"
> button somewhere nearby if the developers were feeling generous).
>  
Speaking about the Save dialog, you can use the filename part as the 
location field, it does autocompletion and all :) I'd have to think 
about Open though. But please - do some mock-uping and I can criticize :)

> Save As
> I dont think Character Coding belongs in the Save Menu I really dont.
> Gnome developers have always given in to the temptation to add extra bits
> to the file chooser when they really shouldn't.
>  
I don't agree with you here. I'd hate to see several popups in 
succession (Iäd phrase this as "One action, one window" rule, but I have 
to think about it more). But I am on you with believing that the 
fileschooser is a useful piece of functionality and there is a 
world-wide conspiracy to get rid of it. I have a felling that the fate 
of the filechooser is very closely tied to the outcome of the 
presidential elections in the US...

nope, just kidding ;P

A decent filechooser is quite easy to do. Windows, KDE and Mac OS X have 
one. The problem is that Gnome wants a radically better one and as a 
result has come up with great ideas but not the simplicity that is 
needed. that is also why the "get rid of it" people have a great argument ;)

> The "we dont need a legacy file chooser" crowd would say that if you have
> nautilus open double clicking the file should open in the correct
> application (but we both know there is often more than one correct
> application).   The application itself should be a drag target.
>  
That must also work, but that is the _lowest common denominator_ There 
are vastly different needs and use cases.

> I know people are sick and tired of hearing all softs of different
> opinions about the file chooser but the Beagle Search tool means a lot
>  
What is the Beagle Search tool? Just send a link and lets keep the 
thread to the topic.

> more messing with the File Chooser will happen so it is necessary to try
> and figure out a way to get applications to at least make their changes in
> a consistant way.
>  
I agee here- While you dont like applications changing the chooser and I 
do, we have to face the fact that they will continue doing so.

> What I have been wondering most of all is that now that we have a good
> clean File Chooser API shouldn't it be possible for those of use who want
> more than the current file chooser provides to create our own File Chooser
> and wholesale replace it across our entire desktop without needing to
> recompile each individual application?
>  
Doesn't the current one allow that. I understood that is nice and 
modular and all?

The best,

L.