Message-ID: <423555E6.7060202 at rftp.com> Date: Mon, 14 Mar 2005 01:14:14 -0800 From: Robert Roessler Organization: Robert's High-performance Software MIME-Version: 1.0 To: Jacques Garrigue 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> In-Reply-To: <20050312.162426.68555891.garrigue at kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jacques GARRIGUE wrote: > From: Robert Roessler > ... >>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@rftp.com http://www.rftp.com