Re: Another status update

Christophe Rhodes <[email protected]> writes:

> I didn't say this in response to your previous summary, so I'll say it
> now: Welcome Back!

Thanks, this time I hope to stay :-) I hadn't really planned to halt clg
development for so long, it just happened to be far too many other
things with higher priority to do (such as real work and finishing my
master thesis).

> This is cool.  Would you mind summarizing how clg relates to the
> various other gtk wrappers that are floating around at the moment?

Without going into too much details, I would say my emphasize is on
creating gtk bindings that doesn't feel like one is programming in
C. This has so far meant hand crafting all the foreign function
definitions (but that will probably change with the next release of gtk,
which will include full introspection), while other gtk wrappers relies
on automatcally generated bindings.

> My last memory of clg was that it was a relatively mop-heavy lispy
> binding of gtk, which transparently handled callbacks despite the
> underlying lisp's lack of cooperation on that front -- I seem to
> recall exporting funcallN() from sbcl for that purpose.  Is that still
> the case?

You remember correctly about clg being mop-heavy; every GObject class has
a "shadow" class with it's own meta class in CLOS. The main reason for
this design is that it should eventually (when gtk gets full
introspection) make it possible to create new widgets by subclassing.

Clg now relies on CMUCL's native callback facility (and Thomas
F. Burdick SBCL port), but it did use funcallN() before I made this
change.

> The other immediate question that I have for you in this relation is
> how you handle, or plan to handle, Unicode strings.  I was able to
> make Rick Taube's gtk bindings do Unicodely things by substituting
> utf8-string for c-string throughout his bindings; I'm afraid I haven't
> had time to look at yours since, oo, 2002 or so, but can you tell me
> how you're planning to deal with this?

So far I haven't dealt with it at all, except manually converting
strings to utf8 when necessary. But I have been thinking about adding
'utf8-string' to my FFI abstraction layer (I wasn't aware that SBCL
already had such a type, since I haven't look at it's unicode support
yet). I'll try to look more into this when time permits.
 
> [...] ,but I'll try to give clg a spin.

That would be nice.

-- 
Espen


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click