help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Further work on Gtk bindings


From: Mike Anderson
Subject: [Help-smalltalk] Further work on Gtk bindings
Date: 27 Feb 2004 22:05:00 +0000

Hi,

Working with Gtk, every so often you find the need to access a field in
a struct that doesn't have an accessor function (not often - that's one
of the things that impresses me about Gtk). Anyway, I've been looking at
generating CStruct definitions for the Gtk structs.

Actually, I've been hacking away at it on and off for a few weeks.

Anyway, I do have a script that will generate *most* of the CStructs,
but I'm coming to the conclusion that it isn't a good idea. Firstly,
there are real technical difficulties with it (one that hit me just
recently was a field declared as guint8 which should be declared as
#int, rather than #byte as you'd expect). Secondly, I feel that it kind
of violates encapsulation, even though you can, of course, access them
in C.

I've tried a different approach, which is to add a class method for
every Gtk struct which returns the size of the C struct. That way you
can add accessor methods in ST as required, without having declarations
for every field. This is a tarball of my gtk subdirectory and a couple
of other modified files.

http://www.gingerbread.plus.com/downloads/structs-sizeof.tgz

(some nasty hacks in the Makefile - you have been warned)

Writing this, it occurs to me that really, the best thing would be to
provide a CStruct definition for the simple structures, like
GdkRectangle, GtkAllocation that would benefit from direct access to
their fields, and custom written accessor functions for those fields
that you really do need to get hold of in the more complex structures
like GtkWidget and GtkDialog (this is almost full circle for me :-( ).

Anyway, I was wondering if anyone else had any thoughts on this.

Incidentally, corrections.diff, in the root of the tarball, contains
fixes for some bugs I identified along the way. However, it's not
correct, because the third part is for the Makefile, not Makefile.in,
and it's not correct - it fixes the symptoms, not the cause, of .order
being generated wrong, and, in any case, GLIB_FILES, ATK_FILES,
PANGO_FILES and GTK_FILES should be generated by the output of
pkg-config, I think. I'll sort that out properly and submit a proper
patch shortly.

Regards,

Mike

Attachment: corrections.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]