Re: Signals with gchar** arguments

["James \"Doc\" Livingston" <doclivingston gmail com>]

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.


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

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.


Cheers,

-- 
"25 grams of wafers and 20 ml of wine undergo transubstantiation and
become the flesh and blood of our Lord. How many Joules of heat are
released by the transformation?" --Theological Physics exam, 1997