Re: File selector talk writeup

[Owen Taylor <otaylor redhat com>]

Thanks for the detailed feedback.

> * Filtering.
> 
>   I don't think much freedom should be given to the programmer in
>   this.  The dialog API should either go the OS X way (specify what 
>   types are allowed to be selected, and only show files of those 
>   types to the user), or the Windows way (specify a set of groups 
>   of types like "JPEG files", "PNG files", "Image files" etc and 
>   let the user pick).  Of course, the user should be allowed to do
>   pattern-based filtering, but I don't see a reason to make that
>   programmatically controlled.

>   Allowing the programmer to make complicated custom filters (e.g.
>   via merging simple filters or allowing filter callbacks) is
>   unnecessary, and also increases the chance that the programmer does
>   something unexpected and confusing (we know how we are).

Basically, what I sketched out was more or less what you've
described as the Windows way. A way for the application to
specify groups of types and gives them human visible names.

The reason that I want to allow both filename globs and 
mime types is because:

 - As you say below, the Simple chooser probably won't have
   a good way of doing MIME types.
 - There may not be an easy way for an application to add
   custom mime types.

So, the filename glob provides a simple way for the application
to specify "Glade files" as *.glade.

The reason that I brought up the idea of callback filters is
because my expectation is that programmers will want them
to do slightly dubious things with the file selector. (Imagine
a file selector for an IDE that just showed the source files
and hid the object files and executable.)

There's always this tension between:

 - The things that programmers really should be doing

 - The things that they want to do.

gtk_widget_modify_foreground() is almost always going to be
used inappropriately, but when we didn't have it, people
just spent a lot of time coming up with compilicated ways
of achieving the same thing.

>   Besides, if one really wants total customization, it is possible
>   to write a different implementation for the underlying "file system"
>   interface.

I wasn't planning to make this interface public, at least at
first. It's going to be the hardest part to get right, and not
making it public at least allows us to leave the door open
for using things like a Nautilus view as a file selector.

>   (Also, the filter probably makes the most sense in the Open dialog 
>   and slightly less sense in the Save dialog, and I think I like the 
>   OS X way of filtering more than the Windows way.)

I'm not quit sure I understand the OS/X way. If you want
to allow the user to select from a list of filters, that list basically
has to be provided by the application, since the file selector
has no idea which of the hundreds of possible mime types are
relevant for this application.

> * Addition of simple controls
> 
>   It is mentioned in the writeup that it should be possible to add a
>   simple control like "Open read-only" to the dialog.  But custom
>   widgets in the file chooser are kinda evil (since they end up being
>   inconsistent across applications, and programmers like to do any
>   sorts of funny things with them); so it would probably be better
>   come up with a more strict interface than "add a control to the
>   no-constraints zone".
> 
>   For example, we could lock down what kinds of controls are allowed
>   go there and add specific interfaces for them, without allowing any
>   further customization.  Right now I can only think of two: "open
>   read only" (for the open dialog) and "save in format X" (for the
>   save dialog).  I'd like the API to have explicit calls to handle
>   these cases, but no fancy do-it-yourself hooks.

Again we get the tension between what application programmers should do,
and what they actually want to do. I'm sure people will abuse
this facility and create ugly monstrosities. But I think 
allowing a place to pack a custom widget in is the simplest
API for the few legitimate uses, and if someone is determined to 
create an ugly monstrosity, they'll manage to do it anyways

> * Other things
> 
>   - Is it really necessary to have a separate, embeddable version of
>     the dialog (i.e. the GtkWidget) instead of just the GtkDialog?  I
>     can't think of a sane reason why you would want to embed it, so
>     I'd stick with just the GtkDialog myself...

The main reason I proposed the split is simple consistency with
GtkColorSelection and GtkFontSelection. I don't really know 
of a _good_ reason for embedding a selection, though if you
want to see an example of doing so, look at the New/Open
dialog of the Qt 'designer' program.

>   - MIME types.  How is a GtkFileChooserSimple going to know about the
>     file types?  Adding something to do MIME type recognition in GTK
>     doesn't sound fun nor good.

A good question. It's certainly a challenge, but on the other
hand, I think supporting something better than filename globs
for file types is important.

The simplest thing would be to just have a file somewhere of
filename pattern to MIME types.

 *.jpg *.JPG => image/jpeg

And so forth. Crude, but better than nothing.

A mime type spec is one of the most important things that needs
to be standardized by freedesktop.org (crucial for ISVs). At 
that point, putting MIME type sniffing in the GTK+ stack wouldn't
be unreasonable.

>   - There should be a special mode for selecting directories.
>     (Although, the Windows custom of using a tree control is probably 
>     not a good idea.)

Yes, certainly. One of those details that didn't make it into
the API sketch.

>   - For bookmarks and recent directories, we probably need specs on
>     freedesktop.org?

That would be best. I was thinking of putting them
into the filesystem object so that we could get GNOME integration
without that, but such a spec is needed for:
 
 - GTK+ fileselector integration into KDE
 - KDE fileselector integration into GNOME
 - OpenOffice/Mozilla file selector into KDE/GNOME

(Note that the spec doesn't replace the need to abstract them
out ... other operating systems will have to do something different.
But it would mean that a single implementation for Unix would
be possible.) 

> * Helping out
> 
>   What is the best way to help at this point?  Would it be helpful if
>   I started to write up some APIs?

If you wanted to do that, I think it would be useful. Converting
my API thoughts into header files was going to be my next step,
but if you want to work on it, it wouldn't hurt for me to spend
the time looking at some of the other big-picture 2.4 items
to see where they are.

Regards,
                                      Owen