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

Lethalman lethalman88 at gmail.com
Wed May 17 16:06:54 UTC 2006


Really a nice job.

About FFI ok, but we need, as you said, some autogenerating tool
because of plugin primitives are much boring to write.

Also an how to install GtkPlugin can be interesting if you can.
For callbacks, i think PyGTK bypass coercing and variable arguments
problems using GClosure.

On 5/17/06, goran at krampe.se <goran at krampe.se> wrote:
> 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.
>

-- 
www.italianpug.org - Italian Python User Group Founder
www.lethalman.net - Thoughts about computer technologies



More information about the Squeak-dev mailing list