Re: First UI component needing replacement.

["Michael T. Babcock" <mbabcock fibrespeed net>]

Wouldn't it make more sense to offer checkboxes next to filenames for
multi-select?

----- Original Message -----
>
> 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.
>
> _______________________________________________
> gnome-gui-list mailing list
> gnome-gui-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-gui-list
>
>
>