Re: First UI component needing replacement.

[Dylan Griffiths <Dylan_G bigfoot com>]

colin z robertson wrote:
> I do it all the time. The last command I entered at the command line
> was "xmms win/music/full_tunes/*.mp3 &". I do the same with The Gimp
> and NEdit as well, even closing The Gimp and running it again just to
> open another set of files. A file open dialog must support selecting
> multiple files.

Yes, but I would not have the select single file dialog and the select
multiple file dialog work in the same way.  The select single file dialog is
very much oriented towards one file, as is.

XMMS has a very nicely modified dialog that seems perfect for this.  I use
it when I add files to my playlist in XMMS.  It has a selection of buttons:

[Add Selected] [Add All] [Close]

With only close closing the dialog.  Such a setup, plus modification to the
layout of the single file dialog, could become an adequate multiple file
dialo (IMO).

> The Mozilla-style single tree view should be one of a set of possible
> views. So the set would be something like: Mozilla style, dual pane
> (Dylan style), single pane (Windows style). The latter two would also
> have options for large icons, small icons, details, etc.

Why do we want Windows style at all?  The style I made was to address some
of its shortfalls, as well as the shortfalls of the GTK+ common file dialog.
 
> I very much like the idea of including the Mozilla-style view into the
> dialog. My only concern is that it often gets very long, requiring a
> large window or lots of scrolling. But if it's optional, and if the
> window can be resized (and stay resized) it shouldn't really be a
> problem.

That was one of my basic requirements: the dialogs must be resizeable, and
they must *remember* the resize as a global variable (in the scope of the
desktop environment).  Anything else is too annoying to use.
 
> I think you've misunderstood what Rodd's saying here. All that's being
> said is that the Mozilla-style view makes sense for saving as well as
> opening. Not that it can save multiple files.

I've played with it, as you suggested.  I don't see this.  All they have is
a combined tree view of files and directories.  For saving, the user
probably wants the non-ambiguity of only being able to select on directory. 
For loading, I think this is better addressed by having a dialog which lets
you go around (via the MRU or normal browsing) and "Add" or "Add all files
in directory" to the list returned.
 
> > Yes, but is that really what we need?  99% of file operations with the
> > common file dialog are opening ONE file, or saving to ONE directory.  I'd
> > rather not spend 80% of my time working to support a 1% special case, thanks
> > :)
> 
> I assure you that opening multiple files is more than 1%. And I really
> don't think implementing a Mozilla-style view would take a vast amount
> of developer time. (Ok, I'm saying this safe in the knowledge that I'm
> not going to be that developer. :) )

What do you think of the somewhat less drastic modification to the file
dialog for many file selection?  Does that meet with your approval?  Because
I would prefer that the common * dialogs look at least vaguely similar to
each other (at least until the user starts to customize the advanced
behaviour :-)).
 
> > I'm not convinced that this could be done easily, if at all.  Nor am I
> > convinced that it even makes sense.  Sorry :(
> 
> With all due respect I get the distinct impression that you don't know
> what you're talking about here. Use of the mozilla-style view would
> make perfect sense when opening files, and, used correctly, I believe
> it could make sense for saving as well. Get yourself the M17 build and
> start browsing your hard disk with it.

The funny thing about saying, "with all due respect," is that people often
say things that make you wonder if they respect you at all.

I did just use Mozilla to double check my impressions of its combined
tree-view thing.  It didn't seem to allow highlighting of multiple files
easily.  And if we did make a version that did that, covering ranges would
be tricky.

Consider: shift+arrow expands the range of select.  Shift+mouse click also
does this.  You can go all the way to the top & botton with shit+home and
shift+end (in sane dialogs).  How do we do multiple select if the user has a
few directories drill into, but not all?  Do we select all the files in all
the directories?  Or do we make it harder to select ranges so the user
doesn't accidently shoot themselves in the foot?

As it stands, there are a lot of creeping issues to do with how we'd handle
selection of files in  a non-arbitrary manor that is similar to how we work
in other dialogs.  If you want to convince me, write down the definite
behaviour this dialog will have, and show me how it will not be a complete
180 from every other dialog's behaviour with regards to file selection.  I
don't mind different dialogs, even different looking, but also throwing out
the basic notions of behaviour is the most evil thing ever.  Just go try to
use a program which regards tab as [close dialog, save file] and enter as
[advance to next field] to know what I mean.


-- 
    www.kuro5hin.org -- technology and culture, from the trenches.