Re: gtk2 news

[Mark Mielke <mark mark mielke cc>]

A more consistent and complete base for future development.

Oh, and lots of bells and whistles too...

The real question is... why limit oneself to Gtk 1.x?

mark



On Tue, Sep 10, 2002 at 12:50:36PM -0700, Andy Robertson wrote:
> 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
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list

-- 
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/