Relationship of LablGTK/GTK signal processing
robertr at rftp.com
Fri Mar 11 22:51:26 CET 2005
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. :)
robertr at rftp.com
More information about the Lablgtk-list