It happens that you want a signal having pointers to strings (gchar**)
as argument. Those arguments are used to retrieve strings in the signal
handler, and return them to the signal emitter. A prominent real-world
example is the "authenticate" signal of SoupSession[1]:
static void
authenticate (SoupSession *session,
/* other arguments... */
gchar **username,
gchar **password,
gpointer user_data)
{
/* ... */
g_free (*username);
*username = g_strdup (lookup_username ());
/* ... */
}
Notice that this use of "gchar**" arguments is different from the usage
as "NULL terminated arrays of strings", aka. "G_TYPE_STRV".
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.
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?
Currently I use the approach of registering an artificial fundamental
type of the name EpcStringPtr to get proper documentation in libepc:
GType
epc_string_ptr_get_type (void)
{
static GType type = G_TYPE_INVALID;
if (!type)
{
static GTypeInfo info = {
0, /* class_size */
NULL, /* base_init */
NULL, /* base_finalize */
NULL, /* class_init */
NULL, /* class_finalize */
NULL, /* class_data */
0, /* instance_size */
0, /* n_preallocs */
NULL, /* instance_init */
NULL /* value_table */
};
static GTypeFundamentalInfo fundamental_info = {
G_TYPE_FLAG_DERIVABLE
};
info.value_table = g_type_value_table_peek (G_TYPE_POINTER);
g_assert (NULL != info.value_table);
type = g_type_register_fundamental (g_type_fundamental_next (),
g_intern_static_string
("EpcStringPtr"),
&info, &fundamental_info, 0);
}
return type;
}
It fulfills my needs of documenting the argument type, but my feeling is
there should be a better solution for this problem. Feels like shooting
birds with cannons ("to break a butterfly on a wheel"?).
Ciao,
Mathias
[1]
http://library.gnome.org/devel/libsoup/2.2/SoupSession.html#SoupSession-authenticate
--
Mathias Hasselmann <mathias hasselmann gmx de>
http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil