Re: dialog response signal class closure

[Kevin Ryde <user42 zip com au>]

muppet <scott asofyet org> writes:
> The problem you are seeing results from the fact that user callbacks
> (e.g.  $dialog->signal_connect (...)) go through the function
> gperl_signal_connect(), which checks with the registry of custom
> marshalers, while using a class closure through
> Glib::Type::register_object()

I thought it had to be something like that, wasn't sure if the two were
meant to take the same route.

>     return $self->signal_chain_from_overridden ($resp);
>
> causes the warning
>
>     Argument "ok" isn't numeric in subroutine entry at response-
> marshaler.pl line 17.

I didn't think of that.

> Now, one other caveat is that you're returning the value from chaining
> up in a signal that returns no value and doesn't have an
> implementation in the parent.  So, you don't actually need to chain up
> from "response".

Ah yes.  That was sorta to preserve default behaviour like "delete-event
destroy by default", but I see that magic comes under the delete-event
event handler, rather than the response handler as such.

> So, it's apparent that overriding the marshaler causes problems for
> signal_chain_from_overridden().  I'm not really sure how we missed
> that before.  A proper fix for this likely involves having a custom
> "chain marshaler" to bookend with the custom signal marshaler, and
> setting up signal_chain_from_overridden() to look for these.

g_signal_get_invocation_hint gives the current active signal does it, to
know what/how to "unmarshall".

> - do the somewhat dirty signal_connect-to-self-in-INIT_INSTANCE so
> that the custom marshaler fires, OR

Yep.  That's where I started, then realized a class default ought to be
cleaner.

>   unless you don't mind simply requiring bindings new enough not to
> have the problem.

That'd be ok, in the fullness of time.

> - define a special set of positive values as custom return codes for
> your module's dialog, and use those constants in both your class
> closure and in external handlers connected to the response signal.
> This one is kinda icky.

I guess it's not too nice if anyone wants to hook the signal or further
subclass and has to put up with non-standard numbers for standard
looking buttons.  Though in what I'm tinkering with that's both unlikely
and anyway I've already got a couple of buttons like "refresh" with
their own numbers where none of the GtkResponseType names correspond.

If I'm interested in delete-event I probably have know what that's going
to come back as in any case, since it comes out of gtk rather than a
specified button id of course.  (Some dialog classes I want to hide on
delete/close and some should destroy.)