Re: [Axiom-developer] User Interface Help

[Ted Kosan]

Tim wrote:

> One primary consideration is the number of languages we need to support.
>
> There is currently no Java in Axiom.  Java is a heavy component to add
> to the build dependency.

One can assume that a JVM needs to be installed on the user's machine
just like it is assumed that FireFox needs to be installed on the
user's machine.



> Javascript is a different story.  Given that we're using the browser
> as a replacement for the C code in graphics and hyperdoc, it seems
> reasonable to use javascript as a replacement language.
>
> I'm learning how to dynamically draw images using javascript and the
> canvas objects to replace the current graphics code. That code will
> get extended to handle things like hypergraphs or other kinds of
> graphs. And the hypergraph facility will eventually get reflected back
> into Spad code so we'll have new ways of drawing things like charts,
> histograms, hypergraphs, etc.
>
> I have hypergraphs "sort of" working (the transformations and drawing
> all work). I'm trying to make the nodes richer so we can get better
> information at each node.
>
> So Javascript seems well integrated while Java is "on the side".
>
> As to the question of supporting "one browser" rather than supporting
> them all, I'm taking the same approach as the rest of the Axiom system.
> That is, I'm not claiming that the code is specific to Firefox (or Linux)
> but I am claiming that I know the code will run on the supported platforms.
> I can make that claim because I build it and test it.
>
> As usual, I expect that Microsoft will be problematic. IE does not
> support the canvas object so there is very little chance of an IE
> front end. I understand that there is a plugin for external canvas
> support in IE but I have not tried it.
>
> However, Firefox on Windows will completely eliminate the whole
> graphics/hyperdoc porting issue as well as unify the two into a
> standard front end. So I suspect that Axiom on Windows will be much
> easier to port in the near future.
>
>
> The whole issue hinges on available time.

If available time is an important issue, why choose to use a
browser/javascript solution for the Axiom front-end and documentation
system when almost everything will take much longer to develop than
with a Java-based solution?

Java is currently the most widely used language for both commercial
and open source use
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) and
this means that there is a huge amount of free Java package available
to help solve almost any problem.  Beyond this, Java's development
tools are some the best available and most of them are open source.  I
have found that the combination of open-source Java packages and
high-quality development tools translate into significantly increased
development speeds.

For example, MathRider represents about 7 months of part time work by
one person and it already has the following capabilities:

    *  Supports multiple scripting languages for both extension of the
application and general use (including Clojure).
    * Interactive 2D graphics (including XY plots and network graphs).
    * Interactive 3D graphics (on the way).
    * Syntax highlighting for over 150 file types (SPAD syntax
highlighting would be easy to add).
    * Numerous programmer's text editor tools.
    * Multiple Console interfaces.
    * Sage-like worksheet interface.
    * A Robust plugin architecture that enables MathRider to be
extended to almost any feasible level.
    * A default CAS with the ability to easily support additional ones.
    * Graphic viewing of the CAS's runtime environment, including the
global state, user functions, and builtin functions (I just added this
capability today and graphic viewing and interaction with the CAS's
data structures is on my todo list.)

Have you had a chance to look at MathRider yet (http://mathrider.org)?
 If not, I encourage you to compare this Java-based solution to the
browser/javascript based solution Axiom is currently working on.

The Crystal system you envision for Axiom would be much easier to
implement in something like MathRider than any browser-based solution
and the nice thing is that almost all of the code can be written in a
scripting language (like Clojure :-)

Ted