Re: [gtk-list] Re: Perl comments

[Kenneth Albanowski <kjahds kjahds com>]

On 20 Oct 1997, Marius Vollmer wrote:

> 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.

Yes, change may well be needed. In any case, I'll continue to work with
mainstream versions, whatever else happens.

> > 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've not looked at it yet, but I will.

> 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.

And, unfortunately, I doubt there is much common ground. My Perl code
primarily consists, now, of glue code, and perl translations of Gtk
functions (in theory this could be automated, but only for functions that
directly match Perl calling conventions.) The remainder (code to build up
a table matching Gtk types to Perl types, and the enumeration and flag
types) is dealt with automatically.

The majority of remaining code is involved with structures (both of the
boxed, non-boxed, and object kind), something I'm not sure how best to
hand. For example, I'm still translating Events to and from native Perl
data, something that may not be best in the long term (and plays merry
havoc with the boxed system.) 

> > 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?

Values are already passed by reference for several signals, as well as the
return value from signals. But this isn't done consistently, and can be
baffling. (Consider the return value from a timeout, which is called
GTK_TYPE_BOOL, but is really stored as GTK_RETLOC_BOOL(arg).) Without
completely consistency, there is no way for my Perl marshalling functions
to deal automatically with all available types.

The timeout_add_interp and idle_add_interp go some direction in unifying
everything, but more work is needed. Ideally, I would love to see a single
style of marshalling function (currently the signal marshaller has a
different signature from the idle/timeout marshaller), and the use of
GTK_TYPE_POINTER changed so that all arguments passed by pointer have
unique types, GTK_TYPE_POINTER_OBJECT, GTK_TYPE_POINTER_INT, etc. 

> 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'.

You mean in your working .defs file? This actually doesn't help me as
much, because the marshalling functions must be dynamic. My signal
marshaller is already looking up the signal name in a table to figure out
what the arguments are. I want to be able to just read the Arg parameters
and get the complete set of information.

On the other hand, having this sort of signal and function definition is
definitely very useful for calling signals and functions in the first
place.

> > 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.

Probably.

> It is also available from
> 
>     http://www.ping.de/sites/zagadka/types.html
> 
> > 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.

As long as it is parsable, it really doesn't matter. I'm using some ad-hoc
perl code to parse it, but I easily could build some more robust code. The
information provided is nearly sufficient.

However, I have noticed one general fault: to make use of a name like
GtkFooBar, in some cases it must be transformed to gtk_foo_bar, and
GTK_FOO_BAR, and perhaps a few other variants. Currently this seems safe
enough to do, but it strikes me that this is not a very reliable
mechanism, and that not all languages may be as adept as Perl in dealing
with these transformations.

> > 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

Good.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)