Re: File selector talk writeup

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-02-15 at 12:28, Ettore Perazzoli wrote:
> 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?

I think even for GNOME apps there are some issues ... is it right
for Gnumeric to install mime types for staroffice and excel
spreadsheets?

The idea of having the application augment the list of mime types
for the non-MIME-system case is reasonable, though:

 - It might seem clunky on systems where extensions do define
   file type (Windows, and apparently now MacOS)

 - People may want to use other patterns in some cases ...
   e.g. *~ to show only backup files or something.

[...]

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

Yeah, it is pretty much a UI decision. If we don't add filter selection
people will doubtless ask for it, but doesn't mean that it is right.

As long applications allow you to export as a filetype, we aren't
going to be able to hide the idea of filetypes from the user, though
that may make sense on theoretical grounds. If I have a directory
full of .xcf files and also .png files that I've exported from them,
viewing only the .xcf files may make sense.

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

Is "Open Read Only" really that generally useful? I brought it up
as an example because it was mentioned before, but it's not something
I've seen very often, and certainly not something that I've wanted
to do very often.

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

Hmm, I'd be interested to see what your API proposal for this is.
It seems to me that if we have 4-5 things of the type:

 gtk_file_chooser_set_show_open_read_only()
 gtk_file_chooser_get_show_open_read_only()
 gtk_file_chooser_get_open_read_only()
 gtk_file_chooser_set_open_read_only()

Plus corresponding properties it's going to make for a big
messy API.

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

I assume if we got MIME type handling standardized gnome-vfs would
switch over to it. Hopefully then gnome-vfs could use GLib when
appropriate, though it would presumably need extra stuff on top as
well.

Regards,
                                                Owen