about summary refs log tree commit diff stats
path: root/drawing.lua
Commit message (Collapse)AuthorAgeFilesLines
* consistent names in a few more placesKartik K. Agaram2022-12-231-1/+1
|
* make love event names consistentKartik K. Agaram2022-12-231-4/+4
| | | | | I want the words to be easy to read, and to use a consistent tense. update and focus seem more timeless; let's make everything like those.
* dedup points while loading drawing from diskKartik K. Agaram2022-09-031-5/+0
|
* distinguish consistently between mouse buttons and other buttonsKartik K. Agaram2022-08-231-2/+2
|
* bugfix: imprecision in drawingKartik K. Agaram2022-08-031-0/+3
| | | | | | | | | | | 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.
* round one coordinateKartik K. Agaram2022-07-301-1/+1
|
* round coordinates to integers in a few placesKartik K. Agaram2022-07-291-7/+11
| | | | | | | | | | | | | 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.
* bugfix: online helpKartik K. Agaram2022-07-221-2/+2
| | | | Broken in the commit before last.
* move drawing.starty into line cacheKartik K. Agaram2022-07-201-46/+57
|
* a more radical attempt at ignoring nil y'sKartik K. Agaram2022-07-131-4/+0
|
* no, bring back that defenseKartik K. Agaram2022-07-131-0/+4
| | | | | | | | | 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.
* a bug I've never run intoKartik K. Agaram2022-07-131-3/+0
| | | | | | 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.
* hoist couple of variables outKartik K. Agaram2022-07-131-3/+6
| | | | This seems to uncover a corner case I'd never run into until now.
* use available variablesKartik K. Agaram2022-07-131-1/+1
|
* more idiomatic variable namesKartik K. Agaram2022-07-131-5/+5
|
* chunking by simple local variableKartik K. Agaram2022-07-131-4/+6
|
* make local functions look differentKartik K. Agaram2022-07-131-6/+6
|
* more chunks, same approachKartik K. Agaram2022-07-131-3/+6
|
* chunk up some long linesKartik K. Agaram2022-07-131-32/+32
| | | | | Hopefully this is more approachable. Though now I'm creating two new temporary functions on every draw. Whether I need them or not.
* drop final mention of state global beyond main.luaKartik K. Agaram2022-07-121-29/+28
| | | | | | | | | | 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?
* replace globals with args in a few functionsKartik K. Agaram2022-07-121-71/+74
| | | | | | | | | - Drawing.draw_shape - Drawing.draw_pending_shape - Drawing.in_drawing - Drawing.find_or_insert_point - Drawing.near - Drawing.pixels
* correct a mis-named thresholdKartik K. Agaram2022-07-121-2/+2
|
* drop heavyweight near check on file load/storeKartik K. Agaram2022-07-121-19/+25
|
* left/right margin -> left/right coordinatesKartik K. Agaram2022-07-121-34/+34
| | | | | Editor state initialization now depends on window dimensions, so we have to more carefully orchestrate startup.
* add state arg to a few functionsKartik K. Agaram2022-07-121-25/+25
| | | | | | | - Drawing.current_drawing - Drawing.select_shape_at_mouse - Drawing.select_point_at_mouse - Drawing.select_drawing_at_mouse
* add state arg to few functionsKartik K. Agaram2022-07-121-2/+2
| | | | | | - draw_help_without_mouse_pressed - draw_help_with_mouse_pressed - current_shape
* add state arg to Drawing.updateKartik K. Agaram2022-07-121-7/+7
|
* add state arg to Drawing.drawKartik K. Agaram2022-07-121-15/+15
|
* add state arg to Drawing.mouse_releasedKartik K. Agaram2022-07-121-20/+20
|
* add state arg to Drawing.keychord_pressedKartik K. Agaram2022-07-121-32/+32
|
* add state arg to Drawing.mouse_pressedKartik K. Agaram2022-07-121-15/+15
|
* group all editor globalsKartik K. Agaram2022-07-121-94/+94
| | | | We're still accessing them through a global. But we'll change that next.
* make colors easier to editKartik K. Agaram2022-07-111-7/+7
|
* stop pretending globals are localKartik K. Agaram2022-07-111-4/+0
| | | | | One advantage of this approach: we don't end up with multiple lexical scopes containing duplicates of the same modules.
* make freehand drawings smootherKartik K. Agaram2022-07-051-1/+17
| | | | | | | | | | | | 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.
* bugfix: 'escape' to cancel a strokeKartik K. Agaram2022-07-051-1/+6
| | | | | | 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.
* right marginKartik K. Agaram2022-06-301-7/+7
|
* rip out notion of Line_widthKartik K. Agaram2022-06-301-7/+7
|
* keep drawings within the line width slider as wellKartik K. Agaram2022-06-221-7/+7
|
* clean upKartik K. Agaram2022-06-171-17/+0
|
* more precise shape selectionKartik K. Agaram2022-06-171-0/+17
| | | | | | | 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.
* correct commit f3abc2cbf2Kartik K. Agaram2022-06-171-7/+22
| | | | | | I can't be trusted to do anything without a test. This should fix #5. Please reopen if it doesn't.
* better handle moving pointsKartik K. Agaram2022-06-171-0/+5
| | | | | This should hopefully address #5. I'm removing some constraints from manhattan lines, rectangles and squares.
* dead codeKartik K. Agaram2022-06-151-45/+0
|
* moveKartik K. Agaram2022-06-151-28/+28
|
* .Kartik K. Agaram2022-06-151-6/+3
|
* stop recording points for arcsKartik K. Agaram2022-06-151-1/+0
| | | | | | 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.
* move current mode indicator slightlyKartik K. Agaram2022-06-151-2/+2
|
* standardize on ordering of casesKartik K. Agaram2022-06-151-9/+9
|
* test: moving a pointKartik K. Agaram2022-06-141-13/+4
| | | | | I found some code in the process that seems unreachable. Some chance of a regression here..
1013' href='#n1013'>1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071