--- Chris Sangwin <sangwinc@for.mat.bham.ac.uk> wrote:
>
>
> If a new GUI is being developed, could I suggest something a little
> more wide reaching? What about a two level approach.
Um - more wide reaching that what?
> Level I would be a documented API for Maxima, to allow a clean
> interface on various levels. This would include (i) the current
> command line interface, (ii) xmaxima, and also projects like TeXMacs.
There is a fairly clean interface - neither Xmaxima nor TeXmacs has any
close ties to the core of Maxima. There was some issue about prompt
designations, but that has been addressed and AFAIK at the moment we
are in good shape for interfacing to external programs. (Sans using
Maxima's mathematical knowledge to assist in generating formatted
output that fits in a document, but that's nontrivial and not related
to this issue.)
What it DOES need is better documentation. But then, that can be said
for most of Maxima.
> Level II would be be the actual details of the GUI.
Which is where much of the work is involved. I don't quite understand
your point - client/server operations have been used with Maxima for a
loooong time, and one decision that was reached a long time ago was
that whatever GUI solution we use will keep this relationship.
> I'm thinking conceptually of the X-windows system, where we perhaps
> have a "maxima-server" and various "clients" which use the functions.
To my understanding this is what we have now.
> Of course, this isn't really going to be a client-server system.
> Just a very clean separation of the various code functions.
Is there some place where the separation currently isn't clean?
> To what extent are the various parts of the current code separated
> out? This include the generation of error messages, and the user
> prompts (eg integrate(x^n,x) ).
AFAIK, the issues with prompts have been resolved. As for error
messages, there is a maxima error system and the errors from the
underlying lisp. For all I know our error system might benefit from an
overhall, but where does this come in in the GUI discussion? As long
as the prompt separation is clean, text error messages can be passed
right on through the prompt to a GUI. It's formatting the mathematical
output that gets tricky, and that's a separate issue from errors.
> This suggestion may make no sense, of course. But it would have many
> advantages, not least the fact that the core CAS functions would be
> separate from an individual user's interface preferences.
Right - I think that was one of the primary reasons the client/server
model was decided on as a good thing to continue. But as far as that
goes, I think we're already there. We just need a good client
interface, and McCLIM looks to be the best long term way (IMHO anyway)
to provide that.
> Does this make any sense?
Considering it's pretty much what we've already done, I'd say yes :-).
The issue is (or rather will be) what tools to use to create the
"official" GUI, what the interface should be like, etc. That'll most
likely be a lively discussion, when the time comes. I'm looking
forward to it, but we can't let it distract us from the (more
important) issues like fixing math bugs, cleaning up a coding style
that predates most modern conventions and thought minimalist
documentation was a virtue, and writing documentation on how the system
works so new users and programmers don't get the urge to run for the
hills. Also, while we do that McCLIM continues to mature, so hopefully
by the time we're ready for a GUI discussion McCLIM will be ready for
us.
CY
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail