user defined signal proposal (was: Re: new signal GtkWidget::user_signal?)

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

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. 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).

> > 
> > So the only objection that might be at all valid is if you
> > are saying that user signals should not be inherited at all.
> > (And should have nothing to do with the inheritence heirarchy)
> 
> exactly.

well, i revert that ;)

> > I'm not sure I believe that. If inheritence offends you, you can
> > always add your user types to GtkObject, and then they (like
> > "user_signal") apply to all objects. 
> 
> i guess you mean GtkObjectClass here.
> there is a significant difference in adding signals to an object
> class, which will support inheritance, and adding signals to
> an objects instantiation. the additional signal will then be valid
> only for the specific instance of an object that the signal got
> added to. so if i add a signal GtkButton::flip_me to a button
> "Flipper" i can only emit the signal on the button "Flipper" and
> no else widgets, not even the "Close" button or the "Choice" radiobutton.

[correcting myself] but this is not supported by the signal mechanism.
it associates all signals with a certain class.

> > Alternatively, it wouldn't be hard to set up a system where each
> > object can have a list of permitted typeless signals that can be
> > emitted for it. But I'm not sure there is much point in that.
> > 
> > > well thanks for digging into the code, but for the reasons mentioned
> > > above, user signals need to be seperated from the internal class signals,
> > > and one issue still to be worked out is, will user signals be added to
> > > the widget or to the widget class?
> > 
> > Yes, that is a question... (see above)
> 
> well, i plan on adding the user_signal facility to gtkobjects once we got
> the reference revolution from marius worked out. i plan to support
> your suggestion of specifying the return values and function parameters
> and will connect the significant data via gtk_object_set_data(). then
> we'll have a flag GTK_USER_SIGNAL that will be set on objects that
> have user signals, and the performance impact will not be nticable,
> becuase it just involves this one flag test for the usual case.

hm, after a deep insight into the code, i'd now say this is the wrong approach.

<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 ;)


> > 
> > Regards,
> >                                         Owen
> 
> ---
> ciaoTJ
> 

---
ciaoTJ