scenario:
slowly press down mouse button and drag to draw a line
release mouse button
Before this commit the point would jump just a little bit on release,
and points would go slightly to the left of where I expect.
Yet another thing it's hard to write an automated test for.
Thanks Lion Kimbro for pointing out this issue.
I still have to use floats for start/end angles of arcs. That might be a
sign that I don't have the right serialization yet for them. Or that
that feature needs to go.
I started out with a hazy idea of only using 8-bit ints for coordinates,
but now I'm not sure how committed I am to that constraint. While the
width is always 256 units, it might be nice to create long portrait
drawings at some point, whose height is greater than 256 units.
Scenario where I ran into it:
start a stroke inside a drawing
press 'o' to switch to circle mode (but any mode switch will do)
The problem is that Text.textinput unconditionally blows away all .y
values. Sometimes we have to wait for a draw() to fill them back in.
The previous commit was failing inside a test that I can't reproduce
manually. Perhaps it's something about how often draw/update run in
practice. Anyways, it's definitely uncovered a real issue.
This is all unfortunate in several ways
- lots of functions have extra args
- table lookups where we used to have a simple variable
- program initialization is a lot more delicate
Let's see if it was worthwhile. Can we now actually build around the
editor component in forks?
Now I might actually use them more, and maybe I can start considering
taking out some shapes. Do I really need circles if I don't provide
ellipses?
Thanks Ivan Reese for the feedback. "What drawings does your tool
encourage?"
Minor note: taking out the deepcopy creates a cute little string like
effect, where the curve grows tighter the slower you draw it.
This has been broken since commit b544e8c357 on May 17 :/
I'm just undoing that commit, which turns out to be completely
unnecessary. And adding a test.
It's important that the error be additive rather than multiplicative,
otherwise the area grows asymmetrically along a line.
Hopefully freehand drawings will work more intuitively now.
It was kinda weird that we were recording the start but not the end.
And moving the start point didn't actually affect the arc.
Let's see if we actually ever need it.