Re: [gtk-list] Perl comments

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:
>
> (First of all, let me apologize to Marius Vollmer: I believe he has a
> patch out that might provide some of the features I am looking for, but I
> just don't have the time to work with anything but the most mainstream
> version.)

It is probably the right decision.  My patch is really somewhat
political because old code will break massively with it.  There is a
easy enough way to retain backward compatability and guile-gtk will
soon include a version of this patch that maintains backward
compatability, but this time I think it is the right thing to break
old code.

> I'm greatly impressed with the new features I find in 970925, especially
> the type system (where GTK_TYPE_WIDGET_FLAGS can inherit from
> GTK_TYPE_ENUM), and the .defs file, which has allowed me to remove a large
> segment of my hand-written code, and replace it with code that is
> completely automatically generated.

I'm very happy that you like it.  In fact, I was about to ask you if
you could use the general concepts of guile-gtk.

I would very much like to somehow unify your Perl bindings and my
Guile ones.  Like, putting all the common stuff into the main Gtk+
disty and making sure that gtk.defs is not too Scheme centric.

Unfortunately, I don't have much time right now.
 
> I've still got a few unresolved glitches. The main one is that my signal
> handler still has to handle each signal individually, since there's no
> possible way to cope with GTK_TYPE_POINTER arguments.

The right thing, as far as I am concerned, is to get rid of
GTK_TYPE_POINTER completely.  For passing `boxed' structures (like
> GdkEvents, or GtkTooltips), there should already be enough support.

> Can I suggest the use of a new GTK_TYPE_INT_POINTER type that
> inherits from GTK_TYPE_POINTER.  This should be extremely simple,
> and would let my signal marshaller automatically deal with pointers
> of known types. (The *RETLOC* macros seem to be a partial step in
> this direction.)

But you seem to be thinking about passing values by reference so that
the called function can modify it, right?

There is no support for that, but it might be worth adding that.  I
think it would ba some kind of `meta' thing.  Not a new bunch of
types, but as a new option for individual parameters.

Right now, there are the ad-hoc options `=' (for default values) and
`null-ok' (for allowing NULL to be passed for a pointer).  Maybe we
can add `by-ref'.

> Another issue is that pointer types (like GTK_TYPE_POINTER and
> GTK_TYPE_STRING) do not make it clear who owns the memory, who should free
> it, and when, which is especially important for the STRING type.

This is written down in the PROPOSAL, which is included in the
guile-gtk disty.  Maybe it's time to review it and include it in the
Gtk+ disty.

It is also available from

    http://www.ping.de/sites/zagadka/types.html

> I've got a slight bone to pick about GdkWindow: I'm of the opinion that
> it's inappropriate to treat GdkPixmap as "a type of" GdkWindow (with the
> result that GdkWindow is mentioned in gtk.defs). Since the various drawing
> functions work on both GdkPixmap's and GdkWindow's, but the window
> functions only work on GdkWindow, it seems to make much more sense to
> treat GdkPixmap as the "base", with GdkWindow and GdkBitmap as inheriting
> from GdkPixmap. (Yes, I realize this doesn't actually affect any code,
> it's just a semantic change.)

I have not thought about this.  There is no provision for inheriting
one `boxed' type from another.  Could be difficult to do in general.

> Note that, ideally, my code should be able to adapt to any additional Gtk
> compatible widgets (at least to the extent of dealing with 'set' style
> code) just by dropping in an appropriate .defs file. I hope this format
> becomes a standard mechanism of describing the contents of widget code. 
> (At the very least, gtk.defs should be installed.) 

Yes, I want to do something along these lines.  Right now, the
gtk.defs thingie is quite Guile and `core-Gtk' centric.  This is not a
good thing.

> In case anyone is interested (I hope these can go into the main
> distribution), here are the .def entries I've had to add to make the file
> usable with my module. There are undoubtedly more enumerations, and
> perhaps more objects, that I've left out.

I have not yet checked them individually, but most of them should be
in guile-gtk-0.7 and in my patch on ftp.gimp.org