On Thu, Aug 2, 2012 at 12:51 PM, Torsten Schoenfeld <kaffeeti...@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
filechooser2.tar.gz
Description: GNU Zip compressed data
_______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
