What should a GUI do; also , why case sensitive?

Michael Reimpell wrote:

>>If I want to typeset, I get the result from macsyma (etc) as TeX.
>>I paste it appropriately in another emacs buffer that has a draft of
>>a paper in it, and I process that, usually via pdflatex, to make
>>a pdf which I view in a separate window.
> 
> It is also desirable to be able to include calculated plots into a paper in 
> publication quality. Luckily, these are again just different types of views, 
> so this functionality can be easily added in the model-view-controller 
> design, once the framework is ready.
The inclusion of plots into a paper being processed through pdflatex
is probably most easily done if the plot is in encapsulated postscript,
but even so this is clumsy. the inclusion
of plots (say from Mathematica into Windows PowerPoint) HAS been
easy:  I click ^C on the plot, go to the other program and click ^V.
Of course there is still a difference between the deliberate composition
mode of latex and the wysiwyg mode of powerpoint. Especially for
the positioning and sizing of plots, I think I'd like wysiwyg.

> 
> 
>>Viewing result all typeset actually does not solve everything
>> because I ordinarily wish
>>to be able to edit the latex source, in case the results are not
>>quite pretty enough. That is why commercial CAS, even if they
>>do on-screen typesetting, also have TeX formatting commands.
> 
> The term "view" in the pattern is meant in a more abstract way. E.g. a 
> MathMLView could be used to display the result in the application window and 
> a LaTeXView could handle the copy to clipboard request. This way you could 
> look at a "all typeset result" and still copy the contents as LaTex markup 
> via a context menu or keyboard shortcut.

Once I edit the Latex markup, all the other views are wrong (unless you
recompute them from the Latex, which is in general not possible, since
Latex -> Maxima cannot be guaranteed.) While you are welcome to think
of the multiple view paradigm as a nice abstraction, I guess it
seems obvious that there have been, for a while, several views  (e.g.
print as lisp data, print via the "displa" program, as latex)
of expressions. There are only limited translations between views,
making it tricky to provide selection of a subexpression from a display .
> 
> 
>>Communication between front-ends and back-ends using MathML may seem
>>like an obvious good idea, and makes nice demos, but is, for any
>>serious use, a REALLY BAD IDEA, unless you put all your important
>>communication in what amounts to a string inserted in a COMMENT field
>>in the MathML.
> 
> I think we all agree that any markup in the communication layer is a really 
> bad idea, that does not allow to loop the output to the input and vice versa. 
> For example if the used language does not allow the output of
> 'integrate(sin(x),x);
> to be used as the next input, it is obviously the wrong choice.
> 
> The second thing we certainly all agree on, are some facts about MathML. It is 
> a verbose format not meant to be hand written. However, it inherits 
> considerable advantages from XML to be used in a view (read: not in anything 
> that has direct contact to the maxima kernel). 
> - XML is license-free, platform-independent and well-supported way of 
> structuring data. There are ready to use SAX and DOM classes for almost all 
> programming languages. Also, there are ready to use views for MathML such as 
> provided by wxMozilla that is used by wxMaxima.
> - XML makes it easy for a computer to generate data, read data, and ensure 
> that the data structure is unambiguous.

Given that maxima / macsyma already generates data (and can read data)
unambiguously as lisp data, license-free, platform-independent, in a form
that can be read by any other lisp program  (and with a page or two of
code, parsed by C, Java, etc.) I view converting it to XML for purposes
of export with some skepticism.  I would have to be confronted with some
real examples of "we can do this better, and it depends on XML" before
being convinced.  Right now, arguments "in principle" or "abstractly
speaking" are not enough.  Of course writing a conversion from lisp to
xml / mathml is not hard, and apparently has already been done, so
I guess that I am just waiting for the convincing applications.
> 
> Therefore the whole burden of math display is handed over to dedicated 
> projects,

But if these are merely partial "demonstration" programs  (the 10% of
the code that does 80% of the job; neglecting the hard parts), then we
have not achieved much.

leaving us with the task to design a well defined communication
> layer to the maxima kernel (model) and a mapping from messages of that layer 
> to mathml (view).

This seems to me not so difficult from a pure Maxima point of view:
there are only a few places where Maxima communicates with the user:
reading/writing command/display,  the "ASK" or "ASKSIGN" routines,
maybe reading/writing from files, printing error messages.  I think
that a human could find these in a day or two in the source code.

 From a Maxima system point of view, the underlying lisp tends to communicate
directly with the user  at a lisp error, or a debugging "break". Since
each lisp has its own conventions at this point, there is some
system-dependent code needed here.

> 
> Michael
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima