CLX, FFIs, and graphics
- From: "C Y" <smustudent1@xxxxxxxxx>
- Date: 30 Oct 2005 08:48:41 -0800
Sorry if this should obvious, but I'm curious about CLX and how it
relates to graphics in Lisp. Normally when discussions about graphics
come up in Linux, they are either a) toolkits built on clx (McCLIM,
Garnet) or b) FFIs to things like TCL, TK, etc.
a) has the problem of not being able to simply use the look and feel of
(KDE/Gnome/what have you) as a drop in - Garnet, for example, appears
to have its "motif" widget style actually implemented as a set of low
level instructions for drawing widgets so they look more or less like
Motif widgets. As far as I can tell it doesn't actually "check" what
Motif looks like on a particular machine - its a static copy of one
particular look and feel. This is highly undesirable in todays world
of themed interfaces, to say nothing of the sheer grunt work involved
with such low level reimplementation. I had thought McCLIM was
supposed to get around that, and I suppose it does a little bit with
the Beagle backend for Mac, but on the Linux side things are rather
less general - all Unix McCLIM apps I've seen use a "motif" look, and
the only really functional backend right now is the CLX backend.
Obviously the desired solution would be to be able to use "real" QT/GTK
menus, scrollbars, etc and let the desktop theme settings take care of
any relevant details whereever possible, and use lower level primatives
only when actually necessary for custom work, but I have no idea if
even CLIM supports that kind of backend layering. Also, all
discussions I have ever seen of making lisp work with anything other
than clx for graphics seem to involve FFIs - would FFIs be necessary
for a non-clx McCLIM backend?
b) has the obvious disadvantage of not being a "real" lisp toolkit in
the sense of not having to worry about the underlying structure of the
toolkit the way McCLIM and Garnet (are supposed to) allow. Also,
perhaps more telling, any application logic implemented using them is
going to be less portable because the dependancy on one particular
toolkit is explicit.
Based on what little I know, it seems that clx is NOT an FFI? If so,
how does it handle working with X? Is there something unique about low
level X that allows clx to avoid using a FFI that cannot be duplicated
for higher level toolkits?
.
- Follow-Ups:
- Re: CLX, FFIs, and graphics
- From: Bulent Murtezaoglu
- Re: CLX, FFIs, and graphics
- Prev by Date: Re: crosswords
- Next by Date: Re: What do we mean by "Identical" ?
- Previous by thread: Re: crosswords
- Next by thread: Re: CLX, FFIs, and graphics
- Index(es):
Relevant Pages
|
