[lgtk-devel] Re: [PATCH] lgtk CVS on SBCL

[Mario S. Mommer]

Hi Damien,

Damien Diederen <diederen at swing.be> writes:
> I did some cleanup action (see attached patch), but I'm unsure the
> result really is an improvement. Ideas on how to cleanup the sbcl-port
> branch are very welcome...

I think it is an improvement. Hey, this stuff is messy, I don't think
we'll find blessable solutions. :)

I mean, this is sbcl/cmucl, which are incredibly similar. I expect no
end of fun trying to port this to clisp, for instance.

> > I did not found them in the Gtk+ distribution. After Googling a bit it
> > seems that they removed them a short while ago. I am currently looking
> > at the .defs that come with the pygtk distribution.
> 
> Ok, I have downloaded the thing now. I have also been looking at the
> `*-api.xml' files bundled with Gtk#, but it looks like they were
> generated from the same source.

My plan for the moment is to create some metadata dir structure and
import it to cvs (as a separate module) and use that as a database. I
plan to put each header in its own dir (where we then have space to
annotate things, etc.) together with the output of h2def.py on it,
plus the annotations in the pygtk .defs files. This can be automated.

> > I am currently just thinking on how to deal with
> > 
> > * Return types
> > 
> >      Lots of Gtk+ funcs return a GtkWidget, even when in the spec it
> >      is said that they return a GtkRadioButton or whatever. For safety
> >      reasons, and because Lisps type system can handle this, I would
> >      prefer them to return the correct type. That implies either rtfm
> >      (lots of it) or some other trick I haven't thought of.
> 
> Maybe I am missing something, but (at least for the gdk and gtk parts):
> 
> * The `is-constructor-of' property looks like a good guess for 
>   constructors.
> 
> * The `define-method's have an implicit first parameter that is of type
>   `of-object', single-dispatch-style.
> 
> The other uses of GtkWidget* I have encountered look quite legitimate.
> Of course, the thing will require a bit of massaging, but at least the
> metadata seems to be there.

The problem is that if you pass an object of the wrong type to a gtk
routine, you risk messing gtk up. The solution I found now involves
GET_OBJECT_TYPE (d'oh). I think this will be easier and will always
work.

> Oh, and I suppose we can use a simple counting-the-stars heuristic to
> detect 'out' parameters (in combination with value/reference type info).

> >From `pango-attributes.h': 
> 
> | (define-function parse_markup
> |   (c-name "pango_parse_markup")
> |   (return-type "gboolean")
> |   (parameters
> |     '("const-char*" "markup_text")
> |     '("int" "length")
> |     '("gunichar" "accel_marker")
> |     '("PangoAttrList**" "attr_list")
> |     '("char**" "text")
> |     '("gunichar*" "accel_char")
> |     '("GError**" "error")
> |   )
> | )

Yes, but what does it do to the arguments? The char** text are
particularly insidious because there is probably some memory
allocation going on that has to be managed. Seme goes for GError, and
PangoAttrList.

> > * Gdk, Atk, Pango, Gobject, Glib,....
> > 
> >      It is a shipload of stuff, some of it requires thought
> >      (&key/&optional args, for instance), lots of it is simply
> >      redundant (all the functions ending in _defaults, for
> >      instance). Others need carefull wrapping, which implies to be
> >      aware of that to begin with.
> 
> Do you have any actual examples of functions that would require careful
> wrapping? I suppose other language bindings suffered the same problem;
> maybe we could extract some awareness from the their generator code?

The above is a candidate :). Essentially, whenever there is more than
one star you have a candidate. gtk_init (it had three stars!) was such
an example, and I bet there are others. All those which have GClosure
as their argument seem to me to be candidates.

pygtk has a large list of overrides, which are essencially that:
wrapped funcs. But their motives might be unrelated to ours.

> >      I don't even know how to manage that process. I do not want to
> >      get lost in the middle of it, since it is really a daunting
> >      amount of stuff. Ideas?
> 
> I will be looking at the Gtk# `glue' and `generator' stuff...

Fine!

> > > > I'll try to write up today what these nexus/capsule/metacapsule stuff
> > > > does and send it either to lgtk-devel or to clump.
> > 
> > I finally didn't manage. Maybe tomorrow - today I updated the website
> > etc.
> 
> There is no urgency, as I'm starting to get a grasp on the way they work
> anyway.

Ok.

I'll apply the patch shortly (thanks!)

Regards,
        Mario.