axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] A Canonical Axiom GUI


From: C Y
Subject: Re: [Axiom-developer] A Canonical Axiom GUI
Date: Fri, 8 Sep 2006 09:23:38 -0700 (PDT)

--- Kai Kaminski <address@hidden> wrote:
> > 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 :-).
>
> It is indeed very different. Of course, the former should be guided
> by the latter. Since we don't really know what a great GUI should
> look like, we'll have to take some educated guesses and then wait for
> feedback.

Right.  I think we probably can make a reasonable guess though.

> > 1.  2-D interactive mathematical display and formatting, 
> > particularly line breaking and font interactions.  Probably the 
> > hardest single part.
>
> This is of interest to other people as well
> (eg. cl-typesetting). Thus it should be done in a separate general
> purpose library (eg. cl-typesetting).

I think we will probably need to be involved with that, but we will
see.

> > 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.
>
> That's been done for other languages already. It would be cool to
> have a flexible plotting library in Lisp. But it's a waste of time
> write now. There are good offerings in other languages, so just use
> them. The Python Matplotlib source is about 30,000 lines, if I
> recall correctly. Do you really want to recreate that effort for the
> sake of purity? I don't.

Eventually, yes I do.  Existing work should be used as a guide, but I
think the eventual goal should be a plotting library so
good/robust/capable that it makes no sense to use anything else.  I
agree right now it is not a priority.

> > That's why I prefer we have our own, that takes good ideas wherever
> > they are found and incorporates them.
>
> And is always last on new developments, and looks like a random 
> collection of CAS GUI features.

I didn't say ONLY incorporated other ideas, or to incorporate all ideas
willy nilly.  Plus, how many really new features have appeared in CAS
work over the last 20 years?

> If the Axiom core has a new feature that requires it to break
> compatibility with older GUI versions, will the release of that 
> feature have to wait for the official GUI to catch up? Even if
> alternative GUIs already support it?

I would argue yes.  I think once we become a mature project the GUI
should be as much a part of providing a good environment as good
documentation.  I can see your point, but how often would such a change
happen in a major way that would break the official GUI and still allow
alternative GUIs to support it faster than the official one? 
Particularly if both the API and the GUI itself are well designed.

> I have the impression that there are quite a few things that we just
> won't agree on. 

Seems like it. :-)

> Since my arguments are often based on speculation I'm
> not really willing to push them much harder. Maybe we could
> instead try to find a common ground.

Logical and reasonable.

> How about the following:
>
> 1) In the Axiom core we create one or more additional Lisp packages
> (in the DEFPACKAGE sense) that provide an API for all the services
> that a GUI needs/wants/whatever.

Makes sense to me.  I would prefer to see Axiom make much better use of
the package system in Lisp, but apparently that will require some
design consideration since the original development pre-dates the
advent of common lisp packages.

> The most important feature would probably be to get the output from
> textual chatter to something with more structure.

Yes.

> 2) We add a *small* and *simple* piece of code that exports that API
>  over a socket interface. We also add a commandline option to enable
>  this feature/configure the port/etc.

Definitely.

Cheers,
CY

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




reply via email to

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