Re: [gtk-list] Re: new signal GtkWidget::user_signal?

[Owen Taylor <owt1 cornell edu>]

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:

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

That's your idea, anyways. But your the one who wanted them
in the first place, so I guess we should let you decide what
you wanted ;-)

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

My point was that your original proposal (adding a "user_signal"
signal) added a signal that could be emitted for any GtkObject.
So that would be the same as adding new signals to GtkObjectClass.

In the above, you say 'GtkButton::flip_me' - does that mean
a signal that can be only appended to button widgets and
widgets of descendant classes? (Just curious)
  
> > 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.

Well, I'm not sure how the details will work out, but I'm sure
we'll see. 

Regarsd,
                                        Owen