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

[Bob McElrath]

As far as drawing graphs, why not just dump out a graph in any kind of
portable format (e.g. postscript, pdf, svg, etc).  A front-end can parse
it and display it.  There are many relevant lisp libraries:
    http://www.cliki.net/graphics%20library
    http://www.cliki.net/plotting

Kai Kaminski address@hidden wrote:
> 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.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    Somewhere, something incredible is waiting to be known. - Carl Sagan

signature.asc
Description: Digital signature