Re: GTK_TYPE_CONST_STRING?

[Owen Taylor <otaylor redhat com>]

Murray Cumming <murrayc usa net> writes:

> signal's whose default handlers take const gchar*, such as
> GtkStatusBar's "text-pushed":
> 
> void	(*text_pushed)	(GtkStatusbar	*statusbar,
> 			 guint		 context_id,
> 			 const gchar	*text);
> 
> are registered as taking a regular GTK_TYPE_STRING, like so:
>  
> statusbar_signals[SIGNAL_TEXT_PUSHED] =
>     gtk_signal_new ("text_pushed",
> 		    GTK_RUN_LAST,
> 		    GTK_CLASS_TYPE (object_class),
> 		    GTK_SIGNAL_OFFSET (GtkStatusbarClass, text_pushed),
> 		    gtk_marshal_VOID__UINT_STRING,
> 		    GTK_TYPE_NONE, 2,
> 		    GTK_TYPE_UINT,
> 		    GTK_TYPE_STRING);
> 
> How can my .defs generation code [1] discover that it's actually a const
> gchar* that's wanted?

Well all G_TYPE_STRING parameters passed in are conceptually
const. You can't modify them. Whether they are const in C or not is
not all that interesting. So, G_TYPE_CONST_STRING wouldn't make much
sense.

If you care about matching the C prototypes for inserting stubs into
the vtable, you'll basically need to do that by header file scanning.
(And you'll need that anyways if you want to support GObject
interfaces or vtables not bound to signals.)

Regards,
                                        Owen