Re: [gtk-list] Re: an additional argument flag

[Kenneth Albanowski <kjahds kjahds com>]

On 23 Feb 1998, Owen Taylor wrote:

>   if (GTK_OBJECT_CLASS (parent_class)->destroy)
>     (* GTK_OBJECT_CLASS (parent_class)->destroy) (object);
> }
> 
> The problem is that last line - basically it either requires writing
> some customf XS code for each signal, or marshalling the arguments
> back from Perl into a GtkArgs structure than calling the C Marshaller
> for the signal on the parent's default handler.

Yes, indeed. Also, we might want to invoke the ancestors default signal
handler manually, which runs into similar marshalling problems.

> 
> If there was a way of connecting a signal handler before
> a "RUN_FIRST" handler, there would be an easy, if inelegant
> way of handling such chaining - simply, if the signal handler
> is chained, don't NULL out the default handler for the overriden
> signal. But adding signals that are connected "before" is
> not really an attractive possibility - this would approximately
> increase overhead by 50% for every signal emission.

Yes, and if we start having three different levels of "before" and "after" 
then perhaps the mechanism isn't working as designed. 

> GTK definitely wasn't designed to allow deriving new widget
> types in interpreted languages (or any language other than C) -
> and I'm somewhat dubious of the worthwhile-ness of the goal.
> The multi-lingual nature of GTK will be best served if new
> widgets are written in C. On the other hand, if people
> want to do it, there should be a way.

I'm of two minds on this. Yes, implementing major widgets in Perl is
almost certainly a poor idea. Then again, given the architecture of Gtk,
it isn't difficult for C code to use the Perl widget once it is created
and in memory.

Also, it may turn out that, in some context, creating a new widget type is
an elegant approach. We might as well try to support it cleanly in all
languages.

Above all, I think that if it can be made feasible, in a clean manner,
then this is a worthwhile goal in itself.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)