Relationship of LablGTK/GTK signal processing

Robert Roessler robertr at
Tue Mar 15 04:12:52 CET 2005

Robert Roessler wrote:

> Jacques GARRIGUE wrote:
>> From: Robert Roessler <robertr at>
>> ...
>>> 3) Marshalling 2: part of why I ask the previous question is that the 
>>> existing GTK widget-ized version of the Scintilla editing component 
>>> does not seem to do anything "special" about the large custom data 
>>> structure that it hands around during signal processing - for 
>>> example, as the last arg to the gtk_signal_emit call.  It just says 
>>> the return type is GTK_TYPE_NONE, and claims 2 parameters: 1 int and 
>>> 1 pointer.
>> Indeed, GTK itself allows to "marshal" arbitray data-structures, by
>> just passing around pointers, and eventually methods to duplicate or
>> free the data. So marshalling at the GTK level does not generally involve
>> changes of representation.
>> However, ocaml data has to be converted to C format, and this is done
>> by the conversion methods in the Gobject.Data module. Note that you
>> actually don't use them directly, but just pass them to higher level
>> function that wrap a complete callback for you. Again propcc uses them
>> automatically, so that you don't need to look inside Gobject yourself.
>> However, if you need to interface a new datatype, that is not a
>> descendant of Gobject, then you may have to write your own conversions,
>> and register them with propcc so that it will use them with the
>> appropriate types.
> Thanks!  All of your other responses make sense and I made any indicated 
> adjustments... but while I am sure your comments on custom marshalling 
> make sense also, it wasn't as obvious what to do about them. :)
> A [hopefully] trivial point is your "ocaml data has to be converted to C 
> format" - from my perspective, I have a C++ widget that is emitting a 
> GTK event with (as mentioned above) 1 int and 1 pointer.  I [thought I] 
> am trying to get my hands on them, so I can use the int, and pass the 
> pointer down to a "ml_..." C function that will create an OCaml record 
> version of the pointed-to data and return it.  So this would seem to be 
> the reverse direction?  I don't believe that I have a need to emit GTK 
> events from OCaml-land that are destined for C-land... although I may 
> run into this as I get further along.
> In any case, I can "see" the events in OCaml code - as long as I just 
> want to see the int, I can use a "GtkSignal.t" record that looks like
> {name="sci-notify"; classe=`scintilla; marshaller=marshal_int}
> and this in fact works as expected (using some of my Scintilla widget 
> control methods, I can control what integer is emitted in subsequent 
> events, so I know I am properly receiving the value in my OCaml callback).
> So while GtkSignal.marshal_int works to get the int, I don't see a 
> marshal_int_and_pointer (ha-ha), nor do I see immediately how to compose 
> one from the available pieces - yet it is obviously possible, and very 
> likely quite easy. :(
> A concrete example of how to construct the marshaller at this level 
> would really help - to emphasize, the struct pointed at is essentially 
> Windows+Scintilla event data - it is not derived from G*-anything.

More progress:

I can get the "g_type" and convert it to a string for each of the 
notify event parameters with (Closure.get_type argv ~pos:1) (Closure.get_type argv ~pos:2)

and see that they are indeed gint and gpointer... but getting my hands 
on the `INT or `POINTER (or whatever they are supposed to be in OCaml) 
values from these parameters is still proving elusive.  Sigh.

Robert Roessler
robertr at

More information about the Lablgtk-list mailing list