Re: File selector talk writeup

[Ettore Perazzoli <ettore ximian com>]

On Thu, 2003-02-13 at 22:19, Jody Goldberg wrote:
> On Thu, Feb 13, 2003 at 09:06:45PM -0500, Ettore wrote:
> >   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.
> 
> Those cases are definitely necessary, but I'd like to see a bit more
> flexibility than that.  Loading some formats requires complex user
> input.  Things like Gnumeric's text import guru.  These make sense
> to have as secondary dialogs that popup once the file selector goes
> down.  However, in other cases all the user needs or wants to
> specify will be something like encoding.  An example would be CSV
> (text based comma seperated values).  Popping up an entire dialog to
> ask this seems like overkill.  Having or allowing an encoding option
> menu/combo in the dialog would be nice.

Makes sense.  If there are enough complicate cases that wouldn't fit in
the scheme I described, maybe we can have an API to just specify the
list of "properties" for the save operation.  Then all the properties
would appear in the dialog with the appropriate widget (i.e. option menu
vs. check button) and you would be able to get their values through a
simple API.

My worry is that a generic "put your widgets here" interface would cause
applications to come up with all sorts of inconsistent hacks, and will
also make it harder to improve the UI in the future if someone comes up
with a better design.  If there has to be an (optional) "encoding"
option menu, then there should be a place and a look for it, and it
should be enforced in the API.

BTW how do they do it in the Windows world?  I don't think the Windows
file dialog APIs actually allow much versatility in customizing the
dialog...  (Of course, Microsoft apps can go beyond the public API, but
still.  :-))

-- Ettore