MaximaWiki - CY's conceptual stuff

I've created a few early stage mockups of GUI ideas.

This is an idea for visual feedback on matching up parenthesis and highlighting which parts of an expression are incomplete.

Here's a couple examples of how selection might work in this scheme.

Another possibly useful idea here would be to click and hold on a function - say integrate, for example, and have all the contents of that expression highlighted in gray.

This is an incomplete mockup of how an McCLIM based GUI might eventually look, although the colors and widgets would probably be different.

A control to add would be how deep nested parenthesis should be before the lines start being drawn.

Comments welcome.

******************************************************************************

Folding parenthesises would also be nice. One would do this by clicking on little minus signs that appear (maybe dynamicly) next to the lines.

Eike

******************************************************************************

Idea for the left hand side menu gestures (assuming the above layout is something close to what ultimately gets used):

Click on a topic (say Matrix, or Integrals) The topic list is immediately replaced with a list of available commands and templates under that topic, with the most "common" one being under the user's mouse. May recenter both list and mouse pointer to central position, depending on usability impact. Common is defined by the person who creates the list of commands, but in most cases there should be something reasonable - for Integrate, say, a graphical template for integrate(expression,x) or a button to trigger the dialog for creating a matrix in the case of the Matrix button. If the user clicks on this button and releases it, that button is selected. If, on the other hand, he clicks and moves the mouse up or down in the z direction further than some maximum value, the pointer stays where it is and the list scrolls by under the pointer. As each button passes under the pointer, it is selected. The "distance" from the initial mouse position in in the z direction dictates the speed with which the list scrolls by. (May want to define some maximum speed based on the size of the list?) Releasing the button disables scroll mode and select button currently under mouse - the user must click and release to select the button. Clicking and holding, and moving the mouse in z, starts scroll again. Right clicking or middle clicking (Shift or Apple button + click on Mac, or possibly moving mouse left or right past some minimum value) will close out the specific list and restor original list and mouse position. If in gestures mode, moving mouse without holding down left click won't change anything.

Alternately, users should be able to select for "normal" mode, which will do whatever is the standard on their platform (scroll bars and free mouse, probably.)

******************************************************************************

Another idea for the underline/(+ -) folding mechanism - rather than having
... replace the expression, have the compressing action create a new variable,
and assign the "hidden" contents to that variable, and display it below.  E.g.:

                       2
                      y         2     z                    3    5
              sin(---------- + x ) + a  (z + y + x + a) + y  + x
                   3
                  z  + b + a

would fold down to:

                       z             3    5
        sin(%hid_1) + a  (%hid_2) + y  + x

                       2
                      y         2
        %hid_1 =  ---------- + x
                   3
                  z  + b + a

        %hid_2 = z + y + x + a

and at user option %hid_1 could itself be futher decomposed:

                       z             3    5
        sin(%hid_1) + a  (%hid_2) + y  + x

                             2
        %hid_1 = %hid_1_1 + x

                         2
                        y
        %hid_1_1 =  ----------
                     3
                    z  + b + a

        %hid_2 = z + y + x + a

The utility of the second operation is marginal in this case, but in a
more general sense this would allow a user to separate out an expression
until everything is visible in a reasonable fashion.  Then, when a user
re-expands an expression, all sub-definitions are replaced and the temp
variables are freed - or in other words the tree collapses back to the
definition.

This should be in addition to proper line breaking support, not a
replacement for it, but it might prove an easier starting point.

Another useful idea for intelligent line aids might be a "display parts" command, which outlines with a black box each part of a graphical display of an equation, each with a part label - this would make it easy to select the relevant parts of the expression in the next input.

Very cool ideas! Another thing that would be nice:

Autocomplete. :-) Ideally it will finish words as you type, and you can press Enter to complete them. Should remember variable names after you've entered them once, too.

Also, some of the things like %i, %pi, %o45 are kind of hard to type quickly or repeatedly. Maybe custom keyboard shortcuts for commonly used symbols? So I could press Ctrl+I and get %I, Ctrl+P and get %Pi. Things of that nature. And for the outputs and inputs, it would be nice to just click (in some special way) the input or output field I want and have its name entered into my input. Or be able to paste the actual expression into the input, of course.

(I am assuming that this imaginary GUI is a combination of text input and GUI input.) I think that is the ideal case; where you can enter it either way. Typing is faster if you remember the syntax, but pointing and clicking in boxes is faster if you don't. Also, each can show errors in the other more clearly. Ideally it would show both at the same time:

You start to type integ.
The interface shows the entire word integrate( for you to press enter

and confirm, like a standard autocomplete in an address bar or word processor. (Or maybe integrate() or integrate( , , ) for you to enter values into each box? That should probably be a configuration option if so. I can see how it would be faster to type those things yourself instead of navigating to fill in the blanks.)

You press Enter to confirm integrate(.
As soon as the word integrate is shown, the graphical input area right

below the text input area shows an integration symbol, with the empty boxes, as shown in the first picture above, Ex3.

Now if you continue typing the argument in the text input line, the

graphical window shows the argument filling up the main argument box as you type.

If, instead, you click in the graphical input area and start typing in one

of the boxes, the text input area is completed as you type instead.

and so on...

Thanks for taking an interest in this! :-). Autocomplete is indeed an interesting idea, and a worthwhile one - one thing I'm not sure of offhand is how to enable a per-character-typed search event for matching commands while using minimal resources. I suppose it requries making a database of all legal toplevel commands and some intelligent search algorithms - I wonder how hard that would be?

I'm interested in autocomplete too. The rledit program (readline wrapper, called by the rmaxima script) takes a file containing keywords as a command line argument. That can contain all the built-in functions and variables. However, I don't know how to enter new keywords at run time. More investigation needed there. But I think I'll commit a word list for rledit/rmaxima so people can try it at least. -- Robert Dodier

In your latter case, that's where the recursive nature of lisp is nice - each input box would be a MathInput environment, and so if we implement autocompletion for a MathInput type it should be available in all MathInput instances. (Providing its done right, of course.)