Progeome readme

Ultimate intentions

Progeome is a very simple program for projective geometry. It only has 12 possible user actions:

1. Create a free point: click the mouse while holding the “p” key, or tap the touchscreen while holding the “p” button. This leaves the point selected.
2. Create a point constrained to a line: same, but on a line.
3. Create a point at the intersection of two lines: same but at the intersection.
4. Select a point or line: tap or click the point or line. This highlights the object and brings up a radial menu of possible actions, which currently contains only one item, that of creating a line between this point and some other point.
5. Create a line: click the mouse on a second point while holding the “l” key with a point selected, or tap the touchscreen while holding the “create line” menu option from selecting a point.
6. Pan the view: drag a single finger or mouse on the canvas without holding down any other buttons.
7. Zoom and rotate the view: use the mousewheel (which only does zoom) or multitouch pinch gesture.
8. Move an object on the canvas: drag it with a finger while holding the “m” button or with a mouse while holding the "m" key.
9. Constrain an object on the canvas to a line or intersection: same as moving, but release over a line or intersection.
10. Delete an object: tap it while holding the “d” button or click it while holding the “d” key.
11. Undo: drag the “d” button to the left or press ^Z.
12. Redo: drag the “d” button to the right or press ^Y.

Internally, the program represents the drawing as a DAG of object dependencies, which is maintained in a topologically sorted order and thus represents a sort of program for redrawing.

The above description of 12 separate actions sounds a bit like a recipe for implementation paralysis. As an initial rough draft that might be achievable within a couple of hours, I am going to implement “create free point”, “select point”, “create line”, and “move point”, as sort of the minimal core that sort of represents the functionality of the application.

This involves three buttons: create-point, create-line, and move. The create-line button gets displayed only when a point is selected, so we need to keep track of the currently-selected point. It doesn’t yet require reordering the objects, since without reconstraining, the order can’t change. Without macros and deletion, you probably can’t practically create enough objects to require incremental redrawing.

So handling a click involves checking which is the currently selected quasimode, which might be nothing, create-line, or create-point, and beginning to display the relevant feedback, which is then updated for every mousemove. Then handling the mouseup event is where we take the actual action; in the nothing case, that might be selecting a point or flashing the create-point button. Flashing the button requires that we have a currently-active-animations list that we step through on each redraw, and that we do redraw periodically, at least while one or more animations are live.

Handling a touch event is only slightly more complicated, because there are potentially multiple touches, and each one may be activating a quasimode or participating in a particular quasimode, which may or may not be the current quasimode. (Indeed, mouse drags too can also be participating in a previously active quasimode; it’s just that there’s only one of them.) So we need to maintain a set of currently active touch events, along with what each of them is doing, so that we can react properly to touchmove and touchend events.

Handling a keyup or keydown event might activate or deactivate a quasimode, and the activated quasimodes go into some kind of ordered list, with the one at the head of the list actually controlling the interaction.

Actually drawing the sketch is pretty simple. Supposing that each point already knows its coordinates, which it will at first because they’re all free, we just walk through the list of objects, drawing each one on the canvas. Points are drawn as filled black circles, lines as thick lines from some point off the canvas to some other point off the canvas. Then we draw the feedbacks, the buttons, and the animations.

Sigh, okay, what I actually managed to get done in two hours is drawing two buttons and drawing some feedback animations in response to touch and click events.

Feedback from Chrome on Android 4.1.2 is that the touchstart events work fine with at least six simultaneous touches, but the animations run at 10fps instead of 60fps. Ancient Android gets even less, maybe 5fps, using setInterval. Also I had a bug where I would enqueue multiple redraw() calls, which had the result that if you have many circles visible they expanded instantly.

At first, I made the circle buttons 32 pixels in radius. However, on my ancient Android, at minimum zoom (which is the only zoom where the coordinates from the touch events are correct) the 32-pixel-radius circle buttons are 6.5 mm in diameter. A normal keyboard key is 18 mm or 19 mm, and at 4.5 mm or 6.5 mm the keys on the phone’s soft keyboard are too small for me. I had been thinking that maybe 11.25 mm would be a more reasonable key size, which suggests 55-pixel-radius circles, which do indeed come out to about 11 mm. This does feel like it would be more reasonable, and I think we can still fit six buttons in the two corners at this kind of spacing, barely.

Current status

I have create-a-free-point, select-a-point, create-a-line, and delete-a-point running and working more or less smoothly, though with a bunch of overdraw and kind of sluggish response. This is enough to try out the interface and feel that it feels pretty good.

There are still a bunch of problems, not to mention unimplemented features:

• I don’t have scrolling disabled completely. I need to get the canvas sized to the screen and positioned on it without margins, and scrolling and zooming disabled entirely, in order to avoid the janky scrolling and zooming stuff. I had this working with some browser on some version of Android in the past, but I can’t find that code now.
• I’m still only getting 10 fps on Android 4.1.2. I’m pretty sure I should be able to get a smooth frame rate, at least 24 and probably 30, and that will make a big difference to the feel of the UI.
• I haven’t yet implemented any kind of useful feedback during quasimode drags (except move!), so it’s hard to tell where you’re going to make a line to or what you’re going to delete. Coupled with the current inability to select lines for deletion, this makes the interface considerably clumsier.
• Zooming isn’t yet implemented, and we’ll need zooming for the quasimode-drag feedback in order to see what you’re doing. This mostly involves decoupling the scene coordinate system, where the points live, from the screen coordinate system, where the UI events and painting live.
• The other big user interface idea I want to validate is dragging on radial menus on the buttons in order to expand the available options.
• Speaking of validating ideas, I haven’t yet tried the interface on more than myself and one other person who saw me use it, so I don’t have much usability feedback yet. But there are a bunch of usability problems I already know about: the buttons aren’t labeled (“d” is not an adequate substitute for a trashcan icon), the scrolling and zooming is janky, the during-drag or even general quasimodal feedback is missing, and the "p" button doesn’t light up when you tap in an empty part of the canvas.
• The user interface latency on my old Android is an abomination. On Mina’s newer one it’s just frustrating. Presumably on an iPhone or maybe a high-end Android machine it would be tolerable? This remains to be tested.
• I’d like to be able to encode sketches in URL fragments for sharing. If I snap points to grid points until the touch is long enough to give a more precise location, probably most points will consume one or two characters: an 8×8 grid only requires a single base64 character.
• So far I don’t have segments, intersections, or circles, but I feel that once I can do a couple more things, those should be pretty easy to add — and they add enormously to the system’s power, especially intersections and circles.

So far, the keyboard/mouse interface has worked surprisingly well as a way to prototype the limited multitouch interface I have so far; I’ve been able to do most of the development on my non-multitouch laptop.