On Thu, Aug 2, 2012 at 12:51 PM, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
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'.
Oops... :) Fixed.
â + $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.
See attached. It's not very robust but very similar to Gtk2 version. There's no new_with_backend anymore, I think. Did you want to see more extensive tests? What about the ginterfaces_ok you used to have? I just included it as a local sub.
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?
I understand, but don't have a good solution yet either. What sticks out is that we'll have to (correct me if I'm wrong) use a series of "use constant $FOO => XX" then, right? See the attached diffs, test, and chooser.pl example program. Kind of weird but could suffice for now. Also, I wasn't sure if you meant disable as in "comment out" or delete, so I have attached both versions. Let me know what you think. Thanks, Dave M
Attachment:
filechooser2.tar.gz
Description: GNU Zip compressed data