Re: filechooserdialog

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_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,
â 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

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 example program.  Kind of weird but could suffice for

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.

Dave M

Attachment: filechooser2.tar.gz
Description: GNU Zip compressed data

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