Re: Enforcing response codes in GtkFileChooserDialog



On Sat, 2004-03-27 at 16:25, Owen Taylor wrote:
> On Fri, 2004-03-26 at 20:23, Federico Mena Quintero wrote:
> 
> > I'm thinking that response_cb() should enforce having such a button.
> > What do people think of having something like this in it:
> > 
> >   if (!has_one_of_those_buttons (dialog))
> >     g_warning ("GtkFileChooserDialog expects to have at least one "
> >                "button with a response code of GTK_RESPONSE_ACCEPT, "
> >                "GTK_RESPONSE_OK, GTK_RESPONSE_YES, or "
> >                "GTK_RESPONSE_APPLY.  Please use one of these response "
> >                "codes rather than a custom one.");
> > 
> > I updated the reference docs to note this quirk.
> 
> 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.
> 
> 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...
> 
> I guess the question is whether the authors of such language bindings
> want:
>  
>  - To make their users have to write code that all other 
>    GtkFileChooserDialog users get for free.
>  - To have to do a new release, possibly with API changes, to
>    redo how they handle buttons on the filechooser.
> 
> (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)

Which bindings do you mean? Now is the time to discuss API changes,
because we have not yet totally API frozen:
http://www.gnome.org/start/2.5/bindings/

And the bindings that are not on that schedule have not API-frozen
either.

-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]