Re: G_TYPE_CCALLBACK

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> hey,
> 
> does anyone of you know of practical use of G_TYPE_CCALLBACK (or better,
> former the GTK_TYPE_CCALLBACK)?
> i'd like to get rid of that and have a G_TYPE_CLOSURE.
> a closure is probably not too uncommon to pass around via signals
> or even to be used as object property (as for signals, i actually
> have a valid use case in mind, though that's for BSE).
> iirc, the scheme bindings originally meant to use ccallback for passing
> around c functions as cons, but i fail to see why they shouldn't use
> a GClosure instead, in case they actually made use of that.
> since with G_TYPE_CCALLBACK->G_TYPE_CLOSURE the assorted parameter
> specification GParamCCallback will become GParamClosure, i wonder
> whether GParamClosure should contain provisions to store a signature
> in form of a G_TYPE_* list. that'll have two advantages, LB code
> can figure and check the required signature upon connection (not
> just deferred to actuall closure invocation) and code generators
> could provide apropriate typedefs (though for that again, it's
> a pitty that the signal system will just take a G_TYPE_CLOSURE
> as parameter, not a full GParamClosure available for code generators).

[ repeating my answer to Tim on IRC for other people's benefit ]

The only case I know where it is used is the funky:

 gtk_object_new (GTK_TYPE_BUTTON,
                 "label", "Hello World",
                 "signal::clicked", print_hello, hello_data,
                 NULL);

Since "signal::clicked" is in no way a property, I think it would
be cleanest to get rid of this feature. But, Tim was a little
reluctant, since it's sort of convenient from C - you can create
a widget with all its properties and signals set up in
a single function call. 

So, what I thought could be done to preserve this is to introduce
some particular C convenience API like:

 g_object_new_connected (GTK_TYPE_BUTTON,
                        "label", "Hello World",
                        NULL,
                        "clicked", print_hello, hello_data,
                        NULL);

Which would keep the capability to do this without complicating
the property/type system as a consequence. This probably also
lets us get rid of the mysterious 5th property to GObject's:

  void (*set_property) (GObject        *object,
                        guint           property_id,
                        const GValue   *value,
                        GParamSpec     *pspec,
                        const gchar    *trailer);

While you might be able to come up with some other use for
the "trailer" (Tim suggested GtkTreeview::column_title::1),
I don't think it's really a good idea - it isn't going to
make sense in a GUI builder, and there is no type information - 
it's just a magic string.

Regards,
                                        Owen