Re: File selector talk writeup

[Ettore Perazzoli <ettore ximian com>]

On Fri, 2003-02-14 at 11:46, Owen Taylor wrote:
> 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.

The second point is only valid for non-GNOME apps, so maybe the file
backend that would be used in a non-GNOME environment could allow the
app to programmatically add MIME types?

> >   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.

Makes sense.

> >   (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.

Right.  The OS X API is simpler; it just allows you specify a set of
allowed extensions, and the dialog will only show the files whose
extension belongs to the set.  There is no combo box that the user can
use to change the filter.

The relevant API is here:

	http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html#//apple_ref/occ/instm/NSOpenPanel/runModalForTypes:

It is kind of lame that they have it based on file extensions instead of
MIME types...  What I like is that the UI and the API are both simpler,
without removing important functionality in practical cases.

If we want to have the multiple filters thing a la Windows, that's also
fine with me though.  It's just a matter of deciding what the GUI design
should be like...

> 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

At least the standard, expected options (presumably the ones that would
be mentioned in the HIG) should have specialized APIs for them, so eg.
you don't have a situation where some apps have "[ ] open _read only",
some have "[ ] _Open Read Only", others have "[ ] _readonly" and the
most wacky ones have "Open Mode: {readonly,readwrite}" with an option
menu.  :-) 

Besides, for a such a common feature it makes sense to have an API
shortcut that doesn't involve creating the widget manually.

> 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.

Yeah, but it would duplicate a lot of functionality with GNOME VFS...

Maybe there is a way to push the MIME type handling part of GNOME VFS
down the stack so GTK can depend on it?  Maybe it could go into GLib?

> >   - For bookmarks and recent directories, we probably need specs on
> >     freedesktop.org?
(...)
> (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.) 

Understood.

> 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.

OK, I'll see if I can come up with something in the following days...

-- Ettore