Re: [gtk-list] Gtk & Perl

[Owen Taylor <owt1 cornell edu>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> Hello folks. I've spent part of the past week writing a Perl 5 Gtk
> extension module, to let Perl use Gtk (& Gdk). Much of it is operational,
> and I'll probably release something to CPAN within a few days. In writing
> the module, I've run across several issues with Gtk that I hope the
> members of this list could either clarify, or possibly work towards
> supporting in future versions of Gtk.

Great! If I had known in advance, I might (maybe) have been able to
save you some work, since I had already had a mostly functioning
version going. But it had some problems, and since I wasn't getting
a release out, I'm more than happy to let a real Perl expert take on
the job.

> First, let me congratulate all of you, and the authors particularly, on
> this library, which seems to bond quite well to Perl.

That was my opinion too when I was working on it.

> Anyhow, working from the 970606 release (is there a later one?):

Nope. Lots of patches, but nothing official.

>  1. Reference counting seems to be inconsistently used in the Gdk objects
> -- it seems reference counts are never incremented, and two decrements are
> needed to free an object. Of course, I may well be misreading the code. 

I take it you mean Gtk objects ... I don't think there is any
reference counting for Gdk objects. I can't answer for Gtk reference
counting, but actually, I'm interested in what you do for Gdk
structures -- I suppose as long as there is never a case where a
malloc'ed Gdk structure is passed into a function and persists (which
I suppose would be broken design), you could just use Perl refernce
counting. 

>  3. The signal mechanism has one great problem, for Perl, and for other
> interpreters, I am sure: the GTK_POINTER type gives no information about
> what _kind_ of types are desired. My Perl binding is quite careful to
> always fully unpack Gtk's C structures into Perl native native structures
> (and to prevent one type from being used where another was expected,)  but
> this is unfortunately impossible when a GTK_POINTER argument is hit. My
> suggestion would be to add additional values for all types used:
> 
>    GTK_PARAM_POINTER_GTK_STYLE
>    GTK_PARAM_POINTER_GDK_EVENT
>    GTK_PARAM_POINTER_INT
>    etc.
> 
> Currently my code has to use an extremely tedious process of figuring out
> exactly what signal occurred and matching that to code which knows the
> appropriate pointer types. It would also be extremely useful to use a
> similar approach for the various enumeration values. Instead of just
> calling them GTK_PARAM_INT, call them GTK_PARAM_ENU_GtkWindowType, or
> somesuch.

I agree wholeheartedly. I had to do pretty much the same sort of
things with signals. (In the .pm for each class, have code that
identified in detail the signature of each signal for that class).

The enum problem is looking like even more of a big deal with the
the new _new/_setv mechanism (see the 970707 simple.c). It would be
really nice if we could have

   $frame->setv ( shadow_type => 'in' )

instead of
   
   $frame->setv ( shadow_type => Gtk->SHADOW_IN )

(And it get's a lot worse than that example in terms of length - 
 e.g., GTK_MENU_FACTORY_MENU_BAR)

But just creating a whole bunch of new enums might cause problems for
code (like the signal handling code) that needs to know the size of
parameters, nothing more. Either there could be a translation function
from long enum types to short types, or possibily there could be a 
type/subtype scheme. (Either way means changing a lot of stuff, but
hopefully mostly internal to GTK)

> 4. The "simple" mechanism for creating widgets and setting widget state
> (accomplished by the _setv functions, among others) is quite difficult to
> support cleanly from Perl, both because of the aforementioned type problem
> for poitners, and because the user must use the original Gtk names even if
> the rest of the library isn't exposed. It would help considerably if it
> were possible to query a class for the list of args it supports, so the
> Perl library could mediate access.

Adding querying sounds pretty simple to me. (Compared to the above.)

Anyways, its great you are working on this. There are lot's of details
I'll be curious to see how you are handling. I also have some example
programs that might be of interest (a 300 line graphical FTP program
that does background transfers...)

Regards,
                                        Owen