Re: filechooserdialog

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?

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