Message-ID: <423652B4.6030303 at rftp.com>
Date: Mon, 14 Mar 2005 19:12:52 -0800
From: Robert Roessler <robertr at rftp.com>
Organization: Robert's High-performance Software
MIME-Version: 1.0
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
CC: lablgtk at math.nagoya-u.ac.jp
Subject: Re: Relationship of LablGTK/GTK signal processing
References: <423212DE.5090007 at rftp.com> <20050312.162426.68555891.garrigue at kurims.kyoto-u.ac.jp> <423555E6.7060202 at rftp.com>
In-Reply-To: <423555E6.7060202 at rftp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Roessler wrote:

> Jacques GARRIGUE wrote:
> 
>> From: Robert Roessler <robertr@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.

More progress:

I can get the "g_type" and convert it to a string for each of the 
notify event parameters with

Type.name (Closure.get_type argv ~pos:1)
Type.name (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@rftp.com
http://www.rftp.com