Relationship of LablGTK/GTK signal processing

Robert Roessler robertr at rftp.com
Fri Mar 11 22:51:26 CET 2005


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 at rftp.com
http://www.rftp.com




More information about the Lablgtk-list mailing list