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

[Mario Mommer]

Damien Diederen <diederen at swing.be> writes:
> I am still thinking about how to clean up the mess I made of lgtk to get
> it to run on SBCL.  While the #+ forest is ugly as hell, I'm afraid
> simply USEing SB-ALIEN & friends in the DEFPACKAGE form instead does not
> cut it: if anything, it will hide non-standard code, and hinder ports to
> less similar implementations.
> 
> Of course, your `port.lisp' file is a start, and I was thinking about
> completing it with lgtk-level abstractions of DEFCALLBACK and
> ENABLE-INTERRUPTS (I suppose you agree such functions are way too
> low-level to be scattered all around the code).

The problem is to find a good interface. In the case of DEFCALLBACK,
I'd say that we can move it to port.lisp. As long as nobody attempts
to port this to, say, CLisp, I see no hurry in wrapping
ENABLE-INTERRUPTS.

> I'm also a bit wary of the PEEK and POKE macros found in
> `dynaslot.lisp', which I suppose have something to do with the lack
> of accessors for some struct members in Gtk+.

Yes, that is exactly what they are for. They are dangerous, but I do
not think they are too dangerous. They are low-level, that's all. They
are only used internally by dynaslot.lisp. dynaslot compiles and
executes a programm to find out the addresses of slots declared with
(add-alien-slots ...); peek and poke are used to get/set stuff from
there. I thing sb-grovel does something similar.

> my pie-in-the-sky dream would be to have lgtk as a strong link to
> modern desktop environments, and to find a way to reconcile very
> high-level GUI programming and fine tuning as a McCLIM backend.  Did
> I say pie-in-the-sky? :)

:) Well, that's the idea. lgtk is only a low-level lib, a thin
wrapper, to build this kind of thing on top of it.

> > Right now I am trying to add a bulk of functionality, mostly using
> > pygtk .defs files.
> 
> That would be great!  Reusable metadata is cool :)
> 
> Were did you get these from?  Are they the ones from the Gtk+
> distribution, or some improved breed only to be found in secret CVS
> repositories?

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.

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.

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

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

> While I was planning to dig into the code to get the full picture
> anyway, such documentation would indeed be a great help; notwithstanding
> the hordes of young Lisp hackers waiting for some code to cut their
> teeth on :)

I am no expert either! I've been doing lisp for ca. 2 years now. The
code is thus probably not the best learning resource, among other
things because it is, well, in a deep alpha stage.

The dephts of it, i.e. all the files that do not contain a reference
to gtk, are (an attempt of a) general framework for managing bindings
to C libs. I plan to separate that from lgtk some day and use it to
write bindings for other libs too.

In any case, don't hesitate to ask if you have questions!

Regards,
        Mario.

> P.S.: Don't hesitate to forward this message to lgtk-devel as you see
> fit.

Here it goes...