gtk2 news

[Scott Smith <ssmith watson wustl edu>]

I emailed Paolo Molaro about the gtk 2.0 port at both his ximian 
and debian addresses and got no response.  Here is what I sent:

----- cut here -----

Hi Paolo,

I'm a member of the gtk-perl mailing list and a developer who uses your
(excellent) Gtk.pm module.  There has been discussion on the list
about the port of the Gtk2 bindings to perl.  A few people, including
myself, want to make it happen if it is not already being done by you or
someone else.

Are you still actively maintaining the Gtk-Perl bindings, or have you
moved-on to other things entirely?

Any info you have would be appreciated.  I hate to start coding just to
find out you have a nearly-done port sitting in some dark corner of your
hard drive.

If you could either reply to the list, or reply to this email so that I
can post it, it would help us out a lot.  I'd like to use gtk2 in my
next perl app.

Thanks in advance,

Scott

========================================
Scott Smith <ssmith watson wustl edu>
Informatics
Genome Sequencing Center
Washington University School of Medicine

----- cut here -----

I really would like to see this done, so I started on it last weekend.

Here is a general overview of what I was thinking, and following that, 
what I've got so far.  Some of the overview is basic if you're into XS.
I'm not, yet, really.  It looks like everyone who has played with it
is roughly on the same page, though I haven't tried inline C yet.
I was shooting for XS.

* Libraries and header files:

The libraries used to compile C programs using Gtk2 are the ones
we want to wrap with Perl modules.  While certain binutils tools like nm
can tell us the names of functions in the library directly, we need,
I believe, the header files to get the exact prototype.

On systems with pkg-config installed, getting the list of both
libraries and header files for gtk2 is easy:

  pkg-config gtk+-2.0 --cflags --libs

The libraries include gtk, gdk, pango, atk, glib, and a few
others upon which gtk is dependent.

* After wrapping the libraries:

While basic wrappers for the libraries would be nice,
all we'd be left with is perl code like:

    use libgtk;
    my $winptr = libgtk::gtk_window_new();
    libgtk::gtk_window_set_title($winptr,"My Title");

The previous wrappers constructed perl classes (packages)
for the various types available in Gtk, and made methods
in the packages which called the real c functions with 
shorter names.  Once the above perl code is possible to execute,
going to this next level should be simple.  All GtkWidget
objects are derived from GObject, and all GObjects have
a GType, for which there are functions in to get 
inheritance information.  In a dynamically typed language
like perl we could pre-build the packages as modules,
or build them on-the-fly at run-time.

The methods which wrap the c-function-equivalents will have
to translate pointers returned from the c library into perl
objects of the correct type (the old version seemed to use
a hashref with a single key/value (_gtk => pointer_value).
This translation will involve construction of a new perl object
when a pointer value is first encountered, and lookup
of an existing perl object on subsequent encounters with the 
pointer.

They will of course also have to extract the c-pointer values from
the perl object ref when passing parameters into the method.

When the C library wants a function pointer:

As was pointed out previously on the list, getting perl to 
call C is a bit more straightforward than getting C to call 
perl back later, via a callback.  I'll get into this after 
the XS stuff below.

* SWIG and XS parsing the headers:

There are two tools typically used to bind C libraries to perl,
xs and swig.  swig is built to work from library header files to 
produce a perl wrapper.  With xs you code the c back-end for a
perl module in a special c/perl hybrid language, but there is a 
script called h2xs which automatically produces xs code for you
from C header files.  

Both h2xs and swig seem like they could do the trick, but both fail
when parsing the gtk header files.  Unfortunately, I can get neither 
of them work on the gtk headers.  h2xs doesn't let you give it
-I parameters to change the include path, but even after
modifying the script to search the gtk directories, the underlying
C::Scan module fails in some way when parsing the header.  Swig also
has issues.

So I wrote my own parser for the gtk-oriented header files.  If 
anyone wants to try to figure out why h2xs or swig do not work, 
and fix them, that would be great.  I was more confident I could
write a parser for the headers myself than I was that I could fix
someone else's, so I did that instead.

* Where things are so-far for me:

I have as script complete which uses pkg-config, gets a list of the 
libraries used by gtk on the system.  I just finished it this morning,
and will try to get it on my web site tonight.

I run the header files used by gtk through the gcc preprocessor to get a
clean super-header, and then scan the super-header for prototypes
for every function in the library possible.  Many function do not
appear to have prototypes, and are possibly not part of the public API.

Each prototype is parsed and a multilevel hash is constructed to 
describe each function.  I just got the parser to not choke on a few
exotic functions last night.

* Here was my tentative plan for what to do next:

1. Extend the script to write the actual xs code for each function.

2. Test to make sure we can build the basic perl wrappers for the libs.
   (like Goran's code but without having to hand-write gtkperl_*
    wrappers)

3. Produce a module which will be directly "used" by the programmer.
   It should:
     . "use" the lib* modules.
     . query the GType system and build a perl inheritance tree.
     . each package generated should know its function prefix
     . AUTOLOAD should create class methods which are wrappers
       for underlyin c functions on the fly.

4. Ensure that the wrappers handle genral perl <-> c object      
   translation.  Creating a GClosure, or anything else with a C
   function pointer, out of aperl closure looked like it might take some
   work, but at first glance it looks like Goran's code is doing it.

5. Work on error handling, using the function prototype info
   to produce clear messages when wrong paramters are passed to
   the gtk wrapper.

Thoughts anyone?

Scott