axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Lisp GUI libraries and a UI for Axiom


From: Kai Kaminski
Subject: [Axiom-developer] Lisp GUI libraries and a UI for Axiom
Date: Thu, 07 Sep 2006 17:26:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin)

Hi,

despite being busy and not reading the list regularly, I couldn't help
but notice the discussions about Lisp GUIs, especially the suggestions
to create Lisp FFI bindings to WxWidgets (formerly WxWindows, see
http://wxwidgets.org). I first present a short, non-exhaustive list of
Lisp GUI libraries that are free, portable and actively maintained. At
the end of this message there are a few thoughts on GUIs for Axiom.

- wxCL (http://www.wxcl-project.org/language/en/)

  Bindings for the WxWidgets library. Yes, they already
  exist. According to the developers they are in alpha state and
  should work on Mac OS X, Windows XP and Linux. They have only been
  tested on the former two, though.

  CFFI (http://cffi.common-lisp.net/project/cffi/) is used to abstract
  away the differences between different Lisp FFIs. CFFI is fully
  supported on almost all significant Lisps and OSs. See
  http://cffi.common-lisp.net/project/cffi/ for details.

- cells-gtk (http://cffi.common-lisp.net/project/cells-gtk/)

  Bindings for GTK using Kenny Tilton's Cells library
  (http://cffi.common-lisp.net/project/cells/), a portable CLOS
  dataflow extension, to ease GUI programming. Uses CFFI (see above).

- Celtk (http://www.tilton-technology.com/Celtk.html)

  Bindings for Tk using cells (see cells-gtk). OpenGL support.


- McClim (http://www.cliki.net/McCLIM)

  This library is still somewhat experimental and depends on X11 (even
  though there is an experimental Mac backend). Active developer
  community and interesting concepts, as well as a standard.

- lisp-cffi-qt4 (http://lisp-cffi-qt4.sourceforge.net/)

  Experimental CFFI bindings to QT4, the library that is used for KDE.


All the libraries mentioned above are in an early state. There are
rough edges and lots of missing functionality, but all of them look
promising. So far I've tried Cells-GTK (on OS X, doesn't run out of
the box) and McClim.

Now that I've presented a list of Lisp GUI libraries, let me argue
that it is irrelevant. 

I do not see any reason why a GUI for Axiom has to be written in
Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why does
every GUI have to be portable? Why should there be only one GUI or
even a canonical GUI anyway?

Different people will want different GUIs. Tim Daly prefers a 'bare'
Emacs with all buffers in Fundamental Mode, whereas I love my Slime
and all the other bells and whistles. Martin Rubey wants to edit his
pamphlets using Emacs, other people can't stand Emacs. Some of the
latter sold their souls to the VI gods, others really want fancy
graphics and icons and toolbars. Finally some people prefer a portable
GUI, whereas others want really tight integration with their OS of
choice.

Trying to provide a single GUI making all these people happy is futile
at best, probably insane and certainly an awful lot of work.

The solution is to separate the GUI from the Axiom core and make GUI
programming easier. The former is pretty easy, just get rid of the GUI
code in $AXIOM/src. That would also get rid of most of the C code and
thereby improve portability of the core. Making GUI programming easier
is a lot more work.

For a GUI to be more useful than an Axiom terminal session, it needs
to be able to understand Axiom's output to some extent. It also needs the 
ability to
query Axiom for all kinds of information, eg

- list all existing variables/functions/types/commands/loaded libraries/etc
- list all functions/commands that are either of a given type or applicable to 
a given object
- where is the documentation for this library/function/command/etc?
- where is the source code for a given function?
- show me all functions/libraries that call/are called by function/library X
- in debugging mode: supply a stack trace

Create an API that supports this kind of functionality and future
versions of itself, and make it available over a socket using a simple
(in every programming language) clear-text protocol. Done. Sooner or
later someone will write a GUI then.


Kai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]