dyna3

Here's a page to record ideas concerning the look and feel and modes of interaction with Dyna3.

A system for creating graphics from text representations that could be a source of ideas is https://nomnoml.com/

It has a very clean look
There is a text representation of the graphical view, that's effortless to show/hide.
That text representation is declarative, and somewhat (although not completely) order-independent.

So I am thinking that we want to pursue some of these ideas to a further extent. It seems to me that any construction should have a declarative text representation, which it's easy to see and manipulate like "source code". There would be a way to create a (named) point or sphere etc, a way to express constraints, a way to express that something is constructed/derived from something else (e.g. M = midpoint(A,B) which I guess is a shorthand for something vaguely like Point M; AM = BM = AB/2; -- I am not proposing actual syntax at this point.)

The idea is that the text representation and the current displayed construction would be kept in sync: there would be a system of tool icons/menus (whichever we think is easier to use, some things might be accessible by icons while others by menus, or maybe we use just one or the other) and mouse interactions/gestures that would allow you to create points, set constraints, etc. Anything you did this way would be reflected in the text representation; and of course any declarations you entered, or deleted, in the text would update the displayed construction. (In nomnoml, you can't manipulate the graphical representation to change the text, it only goes from text to graphics. So that's a really important extension of the idea in Dyna3.)

I think the text representation should be completely order-independent if that's possible, and indeed, there should likely be quick ways to sort it in a variety of ways: by order it was entered, by entity type, by entity name, etc. Or you should just be able to drag entries around as you like.

Some questions:

Does the text representation also record current contingent aspects of the construction? E.g., the position of a point among its allowed positions, even if it is not constrained to that specific position? For example in GeoGebra, if you enter Q=(1, -2) in its text rep, then the point Q is plotted in the graphical view at that position, but it is fully draggable, and as you drag it, the text representation/definition of it changes in the text window. (I think it is choosing rational coordinates, but it is hard to be certain as they are displayed in decimal.) This has a very nice feel to it. If you want to create a point that is pinned to a specific location there's a different command you can write, e.g. F = Point({-1,1}) (there may be other possible commands). Then F is plotted at that location, but with different appearance, and it is not draggable. I don't know that I love those notations, but ideally we would have both of those possibilities in Dyna3.
How do the derivations interact with the declarations? Continuing the example above, does M=midpoint(A,B) stay that way in the text, or does it just expand to Point M; AM = BM = AB/2? The latter would seem to make it harder to see what's going on, so it doesn't seem to be a good idea. But suppose you type out Point X; CX=DX=CD/2; -- does it automatically "collapse" to X = midpoint(C,D)? Or even to be crazier, suppose you do Point X; Segment s = AB; X on s; AX = XB; -- does that also collapse to X = midpoint (A,B)? How far does Dyna3 go in trying to prove that X really is the midpoint of AB? And what happens if that's deduced from a bunch of other declarations and constraints, and so maybe then displayed as a midpoint derivation, but one of the necessary constraints is deleted, does the text representation flip back to some other description of X, and if so, exactly what? This seems like it could be a morass. Perhaps when something is defined as derived from other things, it has a slightly different status -- maybe it doesn't get its own variables, but is always computed on the fly, dragging it is implemented by temporarily adding a draggable thing with the right definition/constraints, which all evaporate after the drag, constraints on it are rephrased internally into constraints on the things it is derived from, etc. This is a perspective in which somehow M = midpoint(P,Q) makes M intrinsically the midpoint of PQ, rather than just currently the midpoint either by accident or even just by other individual constraints, some of which could later be removed, freeing up M to leave from its midpoint. If you use the derived form, then its the whole package, take it or leave it. If you decide you want M just to be equidistant from P and Q rather than the exact midpoint, you really have to redefine M; you can't just eliminate one condition from it. So in that sense a derivation wouldn't be just an abbreviation, it would be more strict than that. That approach seems less fraught.

Other aspects of the interface: -- I think having this solid foundation of synced declarative textual rep and graphical rep then allows for additional interaction modes. For example, we could add keybindings, and maybe selection by typing name. Suppose there are spheres S and U, and you want to impose a tangency constraint on them. Maybe when the graphical view is focused, typing S selects that sphere. And then typing U adds that other sphere to the selection. And then maybe hitting Ctrl-T or Meta-T or something like that imposes the tangency constraint (which would then update the display and the text representation). If we have such keyboard shortcuts, they could be shown on/by the icons/menu items, or be shown when you hover over them, and maybe suggested by a floating tip when you type the command S tangent U.

I am sure there will be many other aspects to the interface; they can be added here and we may need to split up this page as it grows and becomes more detailed.