Re: [Axiom-developer] A Canonical Axiom GUI

[C Y]

Hey Kai!  We never seem to overlap on IRC, do we? ;-)  Sorry about that
- I need xchat to make a noise when someone sends a message to me. 
Hmm...

--- Kai Kaminski <address@hidden> wrote:

> The tool doesn't change, only the GUI. Do you know any other
> successful language that has a canonical GUI? Certainly not C/C++,
> Java, Smalltalk, Lisp, Python, Ruby, Fortran.

Are you saying you regard Axiom as a language?
 
> I certainly hope that implementing the two examples you give doesn't
> require one to be an Axiom expert. Why do you assume that 3rd parties
> are not interested in developing powerful GUIs? Non of the free Lisp
> implementations has an IDE and most people are using Slime, which is
> just great (even though not nearly perfect).

SLIME is quite good, but I'm not sure the cases are comparable.  If you
look around, I think you will find that there are few to no open source
mathematical environments that approach Mathematica's notebook
interface.  Texmacs probably comes the closest of any I am familiar
with, but it is not tightly integrated with the mathematical
environment.  Some, like wxMaxima, are nice and quite functional but I
think we should strive to have a GUI the way Axiom strives to be a CAS
- to be a solution so good that using it is a no-brainer.  Study all
existing solutions, find the best features of them all, research it
(there is existing work on the topic that is quite academic in nature),
and then design the interface using literate programming techniques. 
To me Lisp makes sense as the language of the GUI because that is also
the foundational language Axiom is written in.

> Why can't you provide this experience without a canonical GUI? Linux
> doesn't have a canonical GUI, it doesn't even have any standard
> software.

There are arguments that it suffers because of this, particularly from
the standpoint of those looking to offer commercial software on Linux. 
I admit I don't know, since the only way to find out is to try, but I
suspect that developing a top notch CAS GUI will require those familiar
with Axiom itself to be deeply involved in the process.

> That's why mere mortals don't just download the kernel, but
> instead install Ubuntu, or whatever the latest hip Linux distribution
> is (I don't mean to disparage Ubuntu, as far as I know it's a fine
> system).

Agreed.  But it does result in effort being diffused over many
distributions and many parallel efforts.  This is the nature of open
source and definitely allows for new features to be tried, so I don't
decry it - but I hope that new and advanced features of mathematical
GUIs could be incorporated into a unified, powerful environment for
Axiom instead of having the user forced to sacrifice one feature or
another depending on their choice of GUI.  (Minimalistic interfaces
aside, of course - there the whole point is to have fewer features.)  

> > 1.  I think a default GUI for Axiom would be a Very Good Thing
>
> As I said, I'm not convinced.

No worries.  There is plenty of room here for differing opinions :-).
 
> > 2.  The project is not yet a a point where this should be a major
> > focus for the project as a whole.
>
> That depends on what you mean. I believe the most important thing is
> to make it developer friendly. In particular we must be able to use
> all the open source Lisp libraries that are available. Also, writing
> tools (especially GUIs) for Axiom should be easy.

Right.  What I ment was we shouldn't be (as a project) worrying about
GUI design when we can't run on ANSI lisp yet.
 
> > 4.  Code counts more than opinions, so I'll be quiet until I have
> > more of the former ;-).

> I'm not so sure about that. How can anyone start coding if there is
> no consent of what the core of Axiom is and what features it should
> offer to GUIs?

Well, that's a bit different.  What we should expose to GUIs and how is
probably somewhat separate from how the GUIs use that information.  The
latter is usually where most of the trouble comes in :-).

> Finally I'd be interested in how we could get such a canonical GUI. I
> see two ways, each of which has its fair share of problems.
> 
> 1) We discuss what features the GUI should have and what
> modifications to Axiom's core are necessary. Then some poor soul
> starts coding and after some time (probably measured in years) we
> end up with the canonical GUI as the Axiom gods ordered it (that's
> us).

:-).  I'm beginning to think that most really high quality software
does take years.  TeX, Axiom, BrlCAD...
 
> What if it fails for whatever reason? What if some third party
> builds a GUI that is much more attractive to users than the
> canonical one? Look at GNU Hurd and Linux. I seem to remember that
> Hurd is the 'canonical' GNU OS. Does anyone care?

Well, if what I have heard about Lisp holds true in GUI programming it
should be fairly hard for anybody to create a feature we can't
incorporate one way or another ;-).  The idea of a literate GUI program
should be that it is first about ideas, and second about the
implementation of those ideas.  If we do it right and cover most of the
key elements of such programs from the beginning (and there are many
similar elements) then further extensions of the core functionality
should be managable.  From my standpoint, the key problems are:

1.  2-D interactive mathematical display and formatting, particularly
line breaking and font interactions.  Probably the hardest single part.

2.  2 and 3-D plotting, interactive manipulation, etc.  IZIC has done
some work that I like, and VTK is also very nice - adapting those ideas
and some work that has been done on how to do high quality mathematical
plotting is probably the second hardest part, or even hardest if we
also cover the core algorithms for graphical display and manipulation
ourselves.

3.  IO in various formats.  TeX, LaTeX, openmath, MathML, a file
storage format for Axiom notebooks, Word's equation editor and doc
format, pdf (particularly the interesting new trick of embedding movies
and objects you can interact with).  Communications protocals between
GUI and Axiom core also fall in here.  Here's an interesting one - if
we need to run the Axiom core without a multi-threaded lisp, how do we
stop a job that is running too long?  Killing it is a bit drastic,
since that also loses us any other computations done before, but what
alternatives are there?

4.  Global document structure - in some ways, a Mathematical GUI must
also be a document processor.  Mathematica certainly is.  How do we
handle that issue?  What typesetting engines are available, and which
are suited for interactive work? 
 
> 2) We modify the Axiom core to allow easy development of GUIs. People
>    start building them, first simple, then more involved ones. We
>    pick the 'best'.
> 
>    What if two years later a different GUI is much better? Do we
>    change the canonical GUI? For how long does it have to be the
>    better one?

That's why I prefer we have our own, that takes good ideas wherever
they are found and incorporates them.
 
> Finally let me point out that there really is no best GUI. On Mac OS
> X the perfect GUI must support AppleScript and satisfy the
> expectations of Mac users, who are very picky about UI design.
> Recently I witnessed a discussion about the subtle differences
> between a window's maximize/close button on OS X and Windows.

Yes, it's quite tricky.  My understanding was CLIM was developed in
part to abstract as much of that as possible, although lack of back
ends to GUI libraries sort of limits that potential at the moment.  In
some respects I think the CLIM design was even more ambitious than that
of Java's GUI libraries - the designers wanted the possiblity of native
looks on all supported platforms using native widgets, when available. 
Of course, that's a bit hard in practice and would require a fairly
universal FFI (hence my interest in the CFFI project.)

> Since a single GUI might support several system at once (see Bill's
> work), why not turn the whole thing upside-down? People download
> bundles consisting of a single GUI and several cores (Axiom, GAP,
> whatever).

Because those systems, fundamentally, are not designed to work
together.  I admire the SAGE effort and I think it will be very useful,
but GAP (for example) doesn't share Axiom's type system and so there is
an impediance mismatch between the two systems.  What assumptions is
GAP making that Axiom doesn't know about when it solves a problem, and
are those assumptions ones that are compatible with the ones we would
make?  Does a function name or even a property name mean the same thing
between the two systems?  If we evolve towards proving algorithms, how
do we prove an algorithm used in GAP without doing enough work to go
ahead and implement it in Axiom anyway?  

> PS: I don't mean to say that there shouldn't be a nice, downloadable
> package on Axiom's website featuring a specific GUI. What I'm after
> is independence. Axiom's main branch should contain no GUI-related
> code other than the implementation of the Axiom<->GUI protocol.
 
Well, maybe.  But I think there should be an axiom-gui tree as well
that has the "official" Axiom GUI, which the Axiom project keeps in
sync with any changes to the Axiom core.  And when we build the
complete "system" we should build axiom-gui as well.  We already build
the Hyperdoc program, after all, and that is part of the default
system.  I'd rather have axiom-gui as a directory in the toplevel axiom
branch, and have a ./configure --without-gui option if one doesn't want
it.  When I type .configure  make  make install and then run "axiom" I
would kind of expect the GUI to be the default.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com