Relationship of LablGTK/GTK signal processing

Robert Roessler robertr at rftp.com
Mon Mar 14 10:14:14 CET 2005


Jacques GARRIGUE wrote:

> From: Robert Roessler <robertr at rftp.com>
> ...
>>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.

Robert Roessler
robertr at rftp.com
http://www.rftp.com




More information about the Lablgtk-list mailing list