[Ecls-list] ECL and UIs

[Matthew Mondor]

On Tue, 30 Apr 2013 11:42:12 -0700
Jason Sewall <jasonsewall at gmail.com> wrote:

> I have a C library I have been working on and I'd like to use (Common)
> Lisp to write a UI to go on top of it.
> 
> I first seized upon ECL for the Lisp, since I could easily make an
> interface to the library, and I had a notion at CommonQt might be a
> good way to do the UI. Of course, I can put lots of UI material into
> the C lib and export that to Lisp myself, but I'd really prefer to
> leverage something that already exists.

Other than commonqt perhaps of interest would be cl-gtk.  Some software
also used mcclim or garnet.  On the other hand, if an HTTP interface
could do, this might be the easiest to provide.

> Leaving the details of the individual hurdles I've come across aside,
> I haven't gotten anywhere. It seems like every GUI toolkit for Lisp I
> come across is poorly maintained and/or doesn't work with ECL.

I agree, they often are one-person projects, with the most tested
implementation being the one they personally prefer.  Another issue
with GUIs is that for many users "native look" on their favorite OS
seems to be important.

> I know my way around pure Common Lisp, but I don't have much
> experience with libraries for it.
> 
> What would you folks do? Does anyone do this? It seems like building
> the UI in lisp would be much more flexible and fun than doing it in C!

If you're really willing to write yourself a widget system, then I fully
agree and CLOS would suit very well.  If you're about to do this, you
probably only need rather low level but flexible input/output though,
so something like bindings for Cairo and Pango might be interesting.
Cairo will deal with antialiasing and hardware acceleration when
available, and can also output to Postscript which would allow a
WYSIWYG system, and Pango can deal with text blocks and fonts.  Then
again though, I have no idea about the state of cl-cairo, and if there
exist Pango bindings.

Alternatives might be SDL or CLX (the latter one as part of ECL should
already work on X11 systems currently), but you'd have more work to do
and would likely also need to interface to freetype.  SDL has issues
with complex keyboard input unless you also write your own input
methods and keymap system.  It has partial support for "unicode input"
which is quite limited.  For SDL I've used lispbuilder-sdl in the past,
which was incomplete but usable.  I started writing an ECL-specific
collection of bindings for SDL but it's unfortunately a low-priority
work-in-progress [1].  With either, unless also using OpenGL, hardware
acceleration might not be available.

The other alternative would be to use OpenGL only (possibly with
limited SDL bindings to deal with the screen portably) and to build
everything from scratch over it, including input methods/keymaps and a
cairo-like output system for it, and freetype-based system for
fonts...  If I remember the Blender project did this but are using
Python as their high-level language.

If you want to use existing CL bindings as much as possible, it's
unfortunately true that SBCL is likely to be more supported and tested,
but CFFI is supposed to also work with ECL, so you might want to try
CFFI-based bindings, it has various dependencies but with quicklisp
this might be easy to install and try today.

If you want to use ECL as a "toolchain" to build distributable
executables/libraries, and/or want to use C/C++ along with CL, then
these are some of ECL's strong points.  It's of course also possible
with ECL to use C libraries without having full-fledged clean CL
bindings to the C libraries you want, by writing in C the parts which
need to deal with them, and providing yourself only the higher-level CL
interface you need instead of bindings for every function/structure a C
library offers.  Another advantage of ECL here is that the garbage
collector can also deal with C objects, unlike with most other
implementations and their FFI, because it's the C GC (boehm-gc) that
ECL also uses for its own objects.  ECL also supports native threads on
every OS it supports.

[1]
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/test/mmffi-sdl.lisp
http://mmondor.pulsar-zone.net/img_gallery/screenshots/mmffi-sdl-test3.png
-- 
Matt