Autoconf adventures with GtkPlugin (now it runs in Linux! :))

goran at krampe.se goran at krampe.se
Wed May 17 07:38:05 UTC 2006


Hi Bruno and all!

Bruno has expressed interest in continuing work on my GtkPlugin and what
the hell, it sounded like fun even though we do have wxSqueak these
days, which is an awesome effort btw. But Bruno is on Linux so I burned
a couple of hours fighting with autoconf and friends to get GtkPlugin
building and running in the 3.9-7 unix VM with the vmm image posted by
Ian on squeakvm.org (nice move Ian).

Below are my ramblings after that adventure last night.

"Bruno Luca" <lethalman88 at gmail.com> wrote:
> I've seen the code, however i was thinking of an FFI plugin, what about?

First of all - I actually managed to get GtkPlugin running under Linux
last night. :) It was very late though so I didn't have time to pack it
up for you - but the examples work as they should and the changes were
very few.

Regarding FFI - I have only used FFI a little bit but from what I know
and have heard:

1. It is pretty slow. Fine for infrequent calls but not too good when
calling often.
2. We don't get away with only FFI since we need to do tricks on the
C-side to get callbacks going. And probably other things might pop up
too.
3. Due to #2 above a plugin givs us more freedom and abilities.

My ideal GtkPlugin solution looks something like this:

1. Make a plugin that runs Gtk using a separate gthread so that it runs
using its own event loop (instead of my current hack by driving Gtk from
within Squeak by calling it every 10 ms). The problems with that is (I
gather) how to ensure that the OS mouse and keyboard events find their
way into that thread and doesn't end up sucked into Squeak. I think I
stumbled over that very problem on win32, but it should be solvable I
guess - but who knows, perhaps this is one of the reasons Rob had to
hack the VM for wxSqueak? Apart from not dealing with events I did
manage to get the windows up on the screen at least (using gthread) :).

2. Reuse the work done in PyGtk by either using their .defs files or
generating our own using their h2defs (I think it is called that)
program which is a non-trivial header-file/c-file parser that generates
.defs-files that describes the API in a simple Lisp-style syntax which
is meant to be easy to parse. So we write a parser in Squeak that reads
those .defs files and then generates a mirror class hierarchy of the Gtk
"classes". I presume Rob does something similar in wxSqueak, not sure.

3. Learn about GObject/GCallback etc so that we can code up support for
*generic* callbacks supporting *arbitrary number* and *types* of
arguments etc. I started by coding something that worked for a simple
button callback, just to get going (and it works fine and even uses a
queue inside the plugin so that events are never lost even if Squeak is
slow in pulling them out), but then I lost my momentum trying to
translate that into something more general. There is a demo with two
windows having buttons that trigger prints in Transcript. There are
articles on the net about GObject etc that we need to read. :)

When I get around to zipping up what I have you can then develop the
plugin using this work pattern:

1. Hack in the Squeak side Gtk classes and/or the GtkPlugin class + .c
support files on disk.
2. Using VMMaker, regenerate only the GtkPlugin (using the menu) as an
external plugin (Resulting in a .dll or .so file). This essentially
takes the GtkPlugin class and generates C-code from it.
3. If you have changed/added libs etc, rerun "make" in the /unix/config
directory and rerun "../config/configure" in the bld dir so that you get
a fresh working Makefile for the GtkPlugin (each plugin gets its own
little Makefile).
4. In the bld directory (according to how to build a VM), type "make
plugins" to rebuild the GtkPlugin.
5. From the image, do "Smalltalk unloadModule: 'GtkPlugin'" (IIRC) to
get rid of the old one and then run whatever Gtk example code which will
automatically reload the plugin.

I will put my stuff up later tonight when I get home. In the end I wrote
a 3-line acinclude.m4 and a 2-line Makefile.inc and added two lines to
make.cfg.in (or whatever the file was called). But it needs to be the
right lines. ;) However this should be useful for other plugin writers I
presume - because I use PKG_CHECK_MODULES which seems to be the
"standard" these days for many packages like Gtk, Gnome etc.

regards, Göran

PS. I will put out a more detailed article on the above.



More information about the Squeak-dev mailing list