Re: filechooserdialog

[Torsten Schoenfeld <kaffeetisch gmx de>]

On 28.07.2012 01:42, Dave M wrote:
> I've attached a diff which seems to work.  How best to handle the
> GtkResponseType part?  I just arranged it as a hash with a lookup...
> if it's needed in any other overrides though, we probably need a
> better solution.

Looking good in general.  A few specific comments:

â +    croak 'Usage: Gtk2::FileChooserDialog->new_with_backend'

'new' instead of 'new_with_backend'.

â +    $result->add_button( $varargs[$i], $response_codes{$varargs[$i+1]});

This fails for user-defined (i.e., positive) response codes.  I think it 
should be

  exists $response_codes{$varargs[$i+1]}
    ? $response_codes{$varargs[$i+1]}
    : $varargs[$i+1]

â We need unit tests for the override.

Now for the general GtkResponseType problem.  Unfortunately, I don't see 
an easy way to solve the problem nicely in one go.  The issue is that 
all arguments and return values that conceptually are of type 
GtkResponseType, are actually marked as a plain gint so that C users can 
pass in values that are not actually in the pre-defined enum.  So we 
would have to go through each occurrence of GtkResponseType and add an 
override that does the %reponse_code dance like above.  I think these 
are all cases:

â gtk_dialog_new_with_buttons, gtk_dialog_run, gtk_dialog_response, 
gtk_dialog_add_button, gtk_dialog_add_buttons, 
gtk_dialog_add_action_widget, gtk_dialog_set_default_response, 
gtk_dialog_set_response_sensitive, gtk_dialog_get_response_for_widget, 
gtk_dialog_get_widget_for_response, 
gtk_dialog_set_alternative_button_order, 
gtk_dialog_set_alternative_button_order_from_array (these last two 
probably also need some annotation work first)
â GtkDialog's "response" signal
â gtk_file_chooser_dialog_new
â gtk_recent_chooser_dialog_new, gtk_recent_chooser_dialog_new_for_manager
â gtk_info_bar_new_with_buttons, gtk_info_bar_add_action_widget, 
gtk_info_bar_add_button, gtk_info_bar_add_buttons, 
gtk_info_bar_set_response_sensitive, gtk_info_bar_set_default_response, 
gtk_info_bar_response
â GtkInfoBar's "response" signal

It would probably be best to change all of these in one go. 
Unfortunately, I don't know yet how to handle the "response" signal 
problem with Perl code only (and I'm very reluctant to add XS code).  I 
have some rough ideas, but their implementation would require additional 
code in Glib::Object::Introspection.

So maybe it's better to postpone the general solution of this problem 
for now, i.e. disable the %response_codes stuff in your patch?