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. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
