GNOME.org
 

Re: gtk2 news

Sorry for a stupid question people, but...

What features does GTK 2 give us?  What advantages
does it have?  All I have seen is a more flexible
canvas and a different theme?  What do you all want to
use it for?

Sincerely,
    andy

--- Scott Smith <ssmith watson wustl edu> wrote:

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


=== message truncated ===


__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]