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?
>>>>> "CY" == C Y <C> writes:
[...]
CY> Based on what little I know, it seems that clx is NOT an FFI?
CY> If so, how does it handle working with X? Is there something
CY> unique about low level X that allows clx to avoid using a FFI
CY> that cannot be duplicated for higher level toolkits?
"The X Window System is defined by the X Window System Protocol
Specification, a detailed description of the encoding and the meaning
of requests and events sent between a client and a server. This
standard protocol does not depend on any particular programming
language. As a result, each programming language must define its own
functional interface for using the X protocol. The standard X
interface used by Common Lisp programmers is called CLX. CLX is a set
of data types, functions, and macros which allow a Common Lisp client
program to interact with an X server to send requests and to receive
input events and replies."[1]
So yeah there's something about X that allows CLX to be implemented in
lisp in that it is a specified client/server protocol defined on byte
streams[2]. The higher level toolkits on X are built mostly on xlib (the
CLX equivalent in C) and present a linkable function call etc.
interface, not a client/server interface.
[1] http://common-lisp.net/project/cmucl/doc/clx/1_3_A_Quick_Tour_of_CLX.html
[2] http://www.x.org/X11_protocol.html
cheers,
BM