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

> 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" <[hidden email]> 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.
>