Re: Signals with gchar** arguments

[Murray Cumming <murrayc murrayc com>]

On Thu, 2007-11-15 at 23:28 +1100, James "Doc" Livingston wrote:
> On Thu, 2007-11-15 at 12:52 +0100, Mathias Hasselmann wrote:
> > Currently glib doesn't provide a fundamental type for dealing with that
> > kind of arguments, so usually G_TYPE_POINTER is used as argument for the
> > g_signal_new call registering such signals. Technically this works, but
> > it leads to bad API documentation. The signal argument is documented as
> > "gpointer" whilst being in fact of the type "gchar**", which is quite a
> > difference.
> 
> As well as bad API documentation, it means that you can't use the signal
> from many bindings (such as python), because they can't know what the
> argument is supposed to be.

This happens fairly often, so bindings hand-code their .defs files. For
instance, for gtkmm the *-event signals have to be changed from GdkEvent
to, for instance, GdkButtonEvent. It needs to be improved when pygtk one
day uses the future full GObject introspection.

> > So my question is: How to solve this issue? 
> > 
> >   - Introduce a new fundamental type "G_TYPE_STRING_PTR" duplicating 
> >     the behaviour of "G_TYPE_POINTER" under a new name.
> >   - Patch gtk-doc to retrieve the real argument by inspecting for
> >     instance the signature of the signal's virtual method?
> 
> - Make the return type of the signal be char*, and use an appropriate
> signal accumulator.

That's no good if there are two gchar** parameters, as in this case.

> Exactly what you should do depends on what semantics you want when
> multiple handlers are registered on the signal, but one common method is
> to stop the signal emission as soon as any handler returns a non-NULL
> value, and use that as the return value of the signal.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com