Interface stuff (reply to about three messages)

Well, Yahoo is apparently slow on the uptake, so I'll try to do it this
way...

Jay Belanger wrote:

>Using GtkMathView sounds like a good idea.  
>Was getting it to compile on Windows a tricky affair, do you know?

I gather, from what I saw on the list, that someone had made the
attempt, was successful, and was sending the needed changes back to the
developer, who then discussed some of them to figure out the best
overall solution, and was going to incorporate them as soon as it was
all figured out.  So right now it would be tough, but hopefully by the
point we start messing with it, most of the ground work for cross
platform stuff will be there.  wxWindows bindings for the math stuff,
however, we would probably have to handle, as well as adding input
capabilities.  Input could be tricky (it's currently geared for
output), wxWindows probably somewhat less so.  Either way, a heck of a
lot better than starting from scratch.

>Also, instead of getting GtkMathView to understand Maxima's output,
>wouldn't it make more sense to give Maxima the ability to output in
>MathML? GtkMathView would then be able to deal with the Maxima output,
>and since MathML has aspirations of becoming the lingua franca of
>computer math applications, I would expect this would become useful in
>other areas besides display.

I'm not sure about that, although there may be several advantages. 
Certainly I can see advantages for webpage work - an extension to
Emaxima might allow fairly impressive online math work to be 
done quickly.

>On a slightly different note, MuPAD has an output filter capability;
>the command
>Pref::output(fn)
>will result in all subsequent output being replaced by fn(output).
>I would think that something like this in Maxima would make it easier
>for different frontends to get the output in a useful form.

Quite possibly - my idea there was to have an "environment variable"
that would be set as the program started up, but that approach would be
limiting if different interfaces wanted to communicate with the same
maxima process.  So such a command may be the better way.  (I have no
idea if access from multiple interfaces would be desirable, but just in
case...  Can anyone think of a situation where that would be
desirable?)

Richard Fateman wrote:

>Looking at GtkMathView is helpful.  I think that for
>one direction (output), Maxima could produce MathML and have
>it rendered by GtkMathView. I am not convinced that MathML
>or its rendering by GtkMathView is sufficiently general to
>do everything Maxima might produce, but I have no
>counterexamples. 

I guess it depends on how general we want to make this - if
I had to guess, I'd say 80% of the benefit of typesetting 
mathematics is in actual greek characters, real integral 
signs, sums and square roots, and fractions and matricies that
are actually how they look in the math book.  I think that
MathML can handle that kind of stuff - if Maxima does produce
something that the display widget doesn't know how to format,
it can just output the usual ascii formatting, and if it looks
like it is something that can/should be formatted, we can add
it to wherever we decide to put those rules.  Which raises an
important point - whatever rules we impliment, for whatever 
solution, should be cleanly and easily extendable.    

>The alternative that Jay suggests,
>that GtkMathView could learn about Maxima, is tempting.
>But this does not address
>the extension possibility that one might want to SELECT
>from the display and get the underlying Maxima code.  

I think we might be able to handle that, with some extensions to 
the code.  If everything being displayed is at some level
translated to maxima code (which it has to be, somewhere) then we
can have a function selectiontomaxima(selected) which would run
the conversion and return the maxima code used.  The only problem
I can immediately forsee is if there is something that changes
form in different contexts, and even then there may be ways around
that.  If we generate the MathML in maxima itself, that might
offer some advantages in the way of environment awareness, but
that could get complicated and would probably have to be addressed
in a process of iteration.

>It also
>seems that GtkMathView along with some other
>proposals including TeXmacs, Emaxima
>depends on linux, at least for the moment.
>It would also be nice to be using a solid version of
>whatever program is proposed...

TeXmacs is indeed Linux specific, barring some rather extraordinary
efforts to install support software on Windows.  GtkMathView however,
based on some recient emailings to the GthMathView mail list, can
function on Windows as well.  That's actually one of the things that
attracted me to it - the excellent prospects for use with different
toolkits and platforms.

I agree a solid version would be nice.  I think by the time we are in
shape with the regular code base to take a crack at this, probably the
current shift GtkMathView is undergoing will have been largely achieved
and will be worth working with.

>There is a deeper problem, potentially.  That is, one
>might introduce to Maxima a new form, say from a particular
>application.  This can be done by syntax extension, and the
>maxima display program understands this and does a suitable
>display.
>   I am not sure how flexible the MathML renderer will be
>in such a situation, or if we want to put that too in
>GtkMathView.  It might be OK, but I'm not sure. Or would it
>be simpler to put GtkMathView into Lisp (or call it from
>Lisp as a renderer).

Could you give an example of how this would work?  I'm not
quite sure what you mean by a syntax extension.

>The advantages of the "in house" Maxima display program
>continue to be:
>   a rather deep understanding of the relationship between
>the display and the math, re-rendering subexpressions to
>different forms as specified by space constraints and flags
>(e.g.  exp(x) or e^x?  1/exp(x) or  exp(-x)    etc).

Flags could be handled, I think - the problem would be space
constraints.  How crutial is that, though?  For ordinary 
sessions that I'm used to, it doesn't make a huge difference.
Readibility is the key, not necessarily space - a scrolled 
display can go as long as it needs to.

>Also the possibility of retaining its format "map" so that
>a selection can be made of a subexpression by pointing to
>its image.

We should be able to do this from an external interface as well -
I think symaxx has that ability already.  Or am I misunderstanding
what you mean by selection of a subexpression?

>The main disadvantage seems to be that there is no uniform way of
>printing a particular glyph on a particular spot on the user's
>display.
>(Other disadvantage: someone has to fix up the program in
>Maxima to reference font information, and probably other things.)

That's far beyond my capabilities for the forseeable future, and it's 
still not clear to me what we gain doing that that we can't get with
an external interface.  I know that's probably me not seeing something 
important, though.

CY

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com