Date: Sat, 12 Mar 2005 16:24:26 +0900 (JST)
Message-Id: <20050312.162426.68555891.garrigue at kurims.kyoto-u.ac.jp>
To: robertr at rftp.com
Cc: lablgtk at math.nagoya-u.ac.jp
Subject: Re: Relationship of LablGTK/GTK signal processing
From: Jacques GARRIGUE <garrigue at kurims.kyoto-u.ac.jp>
In-Reply-To: <423212DE.5090007 at rftp.com>
References: <423212DE.5090007 at rftp.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: Robert Roessler <robertr at rftp.com>

> 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?

First one. That is, lablgtk calls GTK with a wrapped ocaml closure, so
that GTK calls this specific closure directly for connected events.
The wrapping is now a bit complicated to follow, because it involves
both gobject.ml and gtkSignal.ml. Basically you just need to define
GtkSignal.t records. propcc can generate them automatically, but it is
not documented :-(

> 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.

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.

> 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)?

There is no explicit rule, except that if your method has 0 arguments
but causes side-effect, it should take () as argument.
Use labels where this makes sense for you.
Use optional arguments when several methods wrap the same operation.

> 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?

Purely idiomatic. This avoids mixing all the methods in the same
class. The cost is very limited: it only needs to allocate 5 words for
each such indirect method call.

> 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?

Then your class should only inherit from GObj.widget.
This is the advantage of separating typing from physical inheritance:
the only reson your editor is a container is that is implemented as
one, eventhough the user is not supposed to use any container-related
method on it.

Jacques