Message-ID: <423212DE.5090007 at rftp.com> Date: Fri, 11 Mar 2005 13:51:26 -0800 From: Robert Roessler Organization: Robert's High-performance Software MIME-Version: 1.0 To: lablgtk at math.nagoya-u.ac.jp Subject: Relationship of LablGTK/GTK signal processing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, My LablGTK wrapping of the Scintilla component's *command set* is complete - I have 320 methods implemented in my scintilla_editor class and a few Scintilla module functions... but of course, that was the easy part. :) And while displaying, searching, cutting and pasting all work in a "LablGTK" program, that is just the underlying Scintilla widget working as it should. So now I have to actually get OCaml code involved with processing the various events and notifications. GTK and its architecture are documented, so I have been able to puzzle out *some* of the workings of LablGTK by "working backwards" from the interfaces with GTK itself (in combination with previous responses from Jacques). What fun. :) So, a few questions - as always, any help is appreciated: 1) What is the model for interfacing LablGTK with GTK signal processing? In the sense of, does LablGTK try to mirror every connect with a GTK connect, or does it try to just see all GTK events and do its own [re]distribution of those based on its own data structures? 2) Marshalling 1: I certainly understand marshalling in the connecting disparate HW/SW platforms case, and in say, cross-thread data accessing, where one is worried about arranging for [possibly] asynchronous access to information to/from different threads. But I get the impression that GTK marshalling is just trying to match up low-level calling conventions... what *is* the story here, at least insofar as it relates to LablGTK's involvement? 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. 4) All but ONE of the 320 scintilla-editor method calls have 0, 1, or 2 parameters... what are the "LablGTK" style issues here? Should all params be labeled? Should any params be labeled? Should only one of the params on arity-2 methods be labeled? Or, is it "cool" to have TWO modules, one without labels and one WITH (which "wraps" the first)? 5) I am a bit mystified about the way the LablGTK connect methods always do "new" when they are invoked... why is this? Not why am I mystified, but why is it done? Is it idiomatic, or essential to the LablGTK signals architecture? 6) I notice that the GTK widget-ized version of Scintilla claims GtkContainer parentage, even though I don't think it actually is used as a GTK container - it will never, I believe, do even as much "containering" as a Button. If this is the case, what are its implications? Should I make sure that I also do the "container" version of derivations for the class itself and its signals? BTW, "marshalling" may be "marshaling" for you - but Google has 446,000 returns for the first, and 186,000 for the second. :) Robert Roessler robertr@rftp.com http://www.rftp.com