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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On Tue, 27 Jan 1998, Owen Taylor wrote:

> 
> Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:
> 
> > actually gtk_object_class_add_signals() will memory leak if invoked
> > more than once per class, because it was intended to be used only
> > once per class instantiation.
> 
> True, it leaks. But that could be trivially fixed with a new
> call that freed the old signal list. Or by redesigning things.

i wanted to point out the original idea of gtk_object_class_add_signals().

> > > works fine for me.
> > 
> > sure, but do this for 5 signals each allocated by a seperate call,
> > with an initial stack of e.g. 24 signals:
> > you will have 25+26+27+28+29 = 135 * sizeof (gint) bytes
> > allocated that are just wasted. 
> 
> We do have the source here.... There is no reason to be limited
> by the /* FIXME */ presently existing.

>   /*  g_free (class->signals); FIXME freeing here causes a segfault */

hu? i thought i had removed that again ;(((
sorry for leaving it in...

> 
> > also user defined signals
> > will then be inherited to new classes if those are instantiated
> > *after* signal addition.
> >
> > e.g. you do
> > 
> > gtk_init();
> > gtk_type_class (gtk_hbox_get_type());
> > /* currently GtkBoxClass & GtkHBoxClass have about 50 signals */
> > gtk_object_class_add_signals ( gtk_type_class (gtk_box_get_type ()),
> >                                &signal, 1);
> > /* now the GtkBoxClass has 51 signals */
> > gtk_type_class (gtk_vbox_get_type());
> > /* now GtkBoxClass has 51 signals, GtkVBoxClass inherited all 51 signals
> >    but GtkHBoxClass still has its initial 50 signals */
> 
> 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.

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

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

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ