Re: Enforcing response codes in GtkFileChooserDialog

[Federico Mena Quintero <federico ximian com>]

On Sat, 2004-03-27 at 09:25, Owen Taylor wrote:
> Well, if you put this warning in, you have to put it in *when*
> the dialog looks for the buttons, not on creation/map/whatever,
> since people could change the button set after creation.

Yeah, I intend to put the check in response_cb().

> But my concern about doing this is that apparently some language
> bindings don't export the ability to set response codes and just
> make up response codes for the users... it is sort of possible
> to get things right with all custom response codes, right? though
> it requires extra code...

The basic problem is that there is no way to know what the client
program will do based on the response code from a widget in the dialog's
action area.  For example, if you have

[Help]          [Cancel]          [Fubarize...]   [Open]
RESPONSE_HELP   RESPONSE_CANCEL   CUSTOM          RESPONSE_ACCEPT

then we can discard RESPONSE_HELP and RESPONSE_CANCEL easily, but there
is no way to discriminate between CUSTOM and RESPONSE_ACCEPT.

One *may* be able to do something reasonable if the action widget also
happens to be the default widget --- but what happens if someone sets
the default widget to Cancel.

Namely, our "response" handler should not change the state of the file
chooser (e.g. switching folders) if the user clicks on an action widget
that does not correspond to "close the dialog, get the filename and do
something with it".

I can change the code so that it switches folders and stops the emission
iff the action widget that was activated is also the default widget. 
The documentation should mention this, of course.  In this case, then we
can maybe remove the code that checks for responses such as
ACCEPT/OK/etc.

> (We could in GTK+ add gtk_file_chooser_dialog_set_accept_response
> or something, but that would be a 2.6 addition, and I'm not
> sure it really helps such language bindings)

This is the other option.  I like it because it presents an API to
indicate the requirement of having an "accept" button.

[We also have some code to discriminate responses in the file-activated
callback.  If the dialog has no default widget, it finds the first
action widget with a non-cancellation response and activates it. 
gtk_file_chooser_dialog_set_accept_response() would be a much nicer way
to do it.]

As for helping language bindings, it would make the API a lot more clear
in that case, same as for the C binding --- we can print a warning at
response time if _set_accept_response() has not ever been called.

But in the meantime, before 2.6.0, what do we do?

  Federico