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

[Owen Taylor <owt1 cornell edu>]

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.

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

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

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)

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. 

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)

Regards,
                                        Owen