GUI toolkits + CL implementations

[jwm-art]

Hi,

I've been looking around the web trying to check out the state of GUI toolkits available for CL. I've not yet settled on any particular implementation yet (clisp/sbcl), still learning the language, but for future reference I was just wondering what the state of particular CL packages providing GUI toolkits is?

Through ABLE, I've seen the TK interface, which is too dated even for my standards. Preferably, I'd like to use GTK as I've used it with C, but the projects seem a bit dead. Am I right, or do they not need updating (ie the auto-api-generation projects)?

Also, some of the GTK CL APIs (or whatever they're called in CL) seem to have preference for SBCL (as opposed to CLISP) which narrows my choice if I want to use CLISP or forces me to use SBCL. Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

(SBCL/CLISP: anything to do with licensing issues? ie BSD/MIT vs GPL, i'm not that up on it, but I generally use the GPL for code I release as I want to give users freedom without users being able to take that freedom from others, I guess, eh.)

[ramarren]

Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

SBCL and CLISP have quite different implementation objectives. CLISP is highly portable and has small image size, but slow, and SBCL has a native compiler, which means it is fast but much harder to port between systems and architectures. Since most open-source Lisp packages authors use Linux, they use primarily SBCL, and hence their packages are usually supported there better.

But, Common Lisp is a standardized language, which means that portable code should work on all conforming implementations, and extensions can usually be papered over with compatibility libraries. This means that this shouldn't really be a deciding implementation factor. I think that SBCL is better for most applications, especially if you are not going to try to deploy your programs on exotic systems.

Through ABLE, I've seen the TK interface, which is too dated even for my standards. Preferably, I'd like to use GTK as I've used it with C, but the projects seem a bit dead. Am I right, or do they not need updating (ie the auto-api-generation projects)?

As for GUIs an option for GTK bindings is cells-gtk, which uses Cells dataflow package. It is somewhat disorganized, and I had to cleanup the code a bit, but it is quite interesting paradigm. My (slightly) cleaned up version of Cells can be found here (note, all github pages have a download button if you don't want to use git):
http://github.com/Ramarren/cells/tree/master
some documentation for Cells itself here:
http://github.com/stefano/cells-doc/tree/master, although note that installations instructions are outdated.
and cells-gtk, again somewhat cleaned up by me:
http://github.com/Ramarren/cells-gtk3/tree/master.

It even has a more or less working OpenGL widget thing. Unfortunately, there is no documentation, but there is a reasonably comprehensive example.

EDIT: I just checked and the demo runs on CLISP as well as SBCL, after I fixed a small bug.

[gugamilare]

If you are using Linux, there is also two very recent bindings for Qt, cl-smoke and commonqt. IMO cl-smoke has a much better (and more Lispy) approach, not to mention that it also provides bindings for the entire kde API, but, to use it, you will have to set mudballs up (which is easy). For both of them you need to install KDE's smoke libraries, which is easy on Linux (just a matter of finding the right package), but it is not that easy on Windows.

About implementations, I believe you don't need to be that concerned right now. If you start using some internal functions of some implementation (e.g. threads, sockets, MOP, ...), it will be very easy to transform your code to use portability libraries instead of internal functions. Porting CL code from implementations is an easy task (ok, not always, but most times). Therefore you should use the implementation you like more. You can even install multiple implementations and eventually test some code in all of them.

[findinglisp]

Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

SBCL and CLISP have quite different implementation objectives. CLISP is highly portable and has small image size, but slow, and SBCL has a native compiler, which means it is fast but much harder to port between systems and architectures. Since most open-source Lisp packages authors use Linux, they use primarily SBCL, and hence their packages are usually supported there better.

Just for the OP's reference, the usage is pretty clearly in SBCL's favor, with CLISP being #2. See...
viewtopic.php?f=2&t=140

But, Common Lisp is a standardized language, which means that portable code should work on all conforming implementations, and extensions can usually be papered over with compatibility libraries. This means that this shouldn't really be a deciding implementation factor. I think that SBCL is better for most applications, especially if you are not going to try to deploy your programs on exotic systems.

Yes, but also to be clear, most GUI toolkits require FFI bindings and FFIs (foreign function interfaces, for the those new to CL) are not a standard part of the language and are thus not typically portable. While there are portability layers (CFFI, UFFI, etc.) that help to smooth over some of the rough spots and provide some measure of FFI portability, they are not perfect and you'll find the most implementation-specific code written for libraries which interface to the outside world and thus cannot rely on standard CL to get the job done.

All that said, Ramarren is quite correct than generally SBCL is the most well-supported of all the implementations, particular on Linux. If you're working on Mac, you might have better luck with Clozure CL (CCL), which has a long Mac history. On Windows, it's a complete crap-shoot, I think. I personally use CLISP on Windows and generally don't do anything that requires more than basic standard CL functionality when I do.

I'd also add to Ramarren's comment about CLISP being "slow." Yes, while slower than SBCL because it's a more-portable byte-compiled implementation, when we say "slow" here, we're still talking the rough speed equivalent of other scripting languages such as Perl, Python, Ruby, etc. And yes, I know those all have a wide speed range as well. The point is, we aren't talking about something pitifully slow or unusable. But as Ramarren points out, SBCL is a native compiler which is faster but more difficult to port.

[hrapof]

I'm using Cells-GTK and CLG (two GTK bindings) with cl-opengl and cairo bindings (from CLG) on SBCL/Linux for real-time data visualization. I have no need to port the application to Windows, but if I should, I'd try ClozureCL + either of these GTK bindings, as GTK is avaivable for Windows, too.

[aerique]

For GTK there's also GTK-server which is pretty easy to get started with, although it won't be very Lispy. It doesn't need an FFI and it is cross-platform.

It does have its limitations which are hard to work around but for simple interfaces it should be enough. I was able to hack this together almost a year ago: http://www.gtk-server.org/reports-20080915.png

Nowadays I would probably use CLG though.

[nuntius]

Through ABLE, I've seen the TK interface, which is too dated even for my standards.

Try upgrading TK. The latest versions look *much* better than what comes stock with most linux distros or the latest OS X.

LTK is my current CL gui choice because it is stable, easy to install, and cross-platform.