Re: [gtk-list] user defined signal proposal (was: Re: new signal GtkWidget::user_signal?)

[Owen Taylor <owt1 cornell edu>]

> On Thu, 29 Jan 1998, Tim Janik wrote:
> 
> > On Tue, 27 Jan 1998, Owen Taylor wrote:
> > 
> > > 
> > > If you want HBox and VBox to be consistent, you could make
> > > gtk_signal_emit_by_type dynamically search the parent classes and just
> > > store the signals for each widget by themselves.  It would have a
> > > neglible impact on speed, would allow fixing up the
> > > problems with add_signals, and would save a bit of memory.
> > 
> > but this isn't needed as the inheritance has full support for
> > the parents signals.
> > the user_signals are a different issue and are to be implemented
> > apart from the normal inheritance system. they are not even supposed
> > to go into the widget class.
> 
> blah, blah, i talked nonsense there ;)
> 
> there exists no function like gtk_signal_emit_by_type, i guess you mean
> either gtk_signal_lookup() which does the lookup for parents already,
> or gtk_signal_connect_by_type() which is the only location that needs
> to be changed. 

connect_by_type is what I meant...

> if we change gtk_signal_connect_by_type() to lookup in
> the parent class as well, we get your speed/memory improvement and
> don't even have that much of a performance impact. it also sounds
> quite reasonable to do that as gtk_object_class_add_signals() becomes
> a real signal add function then, and the inheritance problem is elegantly
> solved (the mechanism is already there, it's just that the `front-end'
> gtk_signal_connect_by_type() doesn't support it to it's fullest extend).

I think we are talking about the same thing here. Just to make 
sure, what I was thinking was that when the parent class was
copied for a new class, the ->signals member would be zeroed out.
(connect_by_type would skip to the parent class's signal list)

Then add_signals wouldn't have to worry about accidently freeing
the parent's signal list, and would just add the distinct new
to the class's own list.

[...]
> <PROPOSAL>
> i think we should implement the lookup through the parent class in
> gtk_signal_connect_by_type(), this also gives us the possibility to
> do the memory cleanups for gtk_object_class_add_signals().
> 
> also we should add the two lines from owen to check for func_offset==0 upon
> default handler invokation.
> 
> then provide a function
> void    gtk_object_class_add_user_signal  (GtkObjectClass     *klass,
>                                            const gchar        *name,
>                                            GtkSignalMarshaller marshaller,
>                                            GtkType             return_val,
>                                            gint                nparams,
>                                            ...);
> 
> this only requires gtk_signal_newv() which can easily be produced from
> gtk_signal_new(), and we are set for user defined signal additions, identified
> by strings, supporting return values and function parameters plus full
> inheritance in the used performance friendly manner.
> 
> the function gtk_object_class_add_user_signal() isn't really needed for
> providing user defined signals, but because of the implication of a
> func_offset of 0 and the pointlessness of GtkSignalRunType with user_signals,
> it seems reasonable to provide such a function.
> </PROPOSAL>
> 
> (now i guess this will even fully fit owens requirements ;)

It look like you managed, despite my best efforts, to figure
out what I meant to say. :-) If the above meets your requirements,
I think it is definitely the right way to handle things. 

                                        Owen