diff options
| author | Charlie Root <root@dangofactory.local> | 2026-10-05 23:58:26 +0900 |
|---|---|---|
| committer | Charlie Root <root@dangofactory.local> | 2026-10-05 23:58:26 +0900 |
| commit | e0465ad93dd2d2123a7cd6eb1bf497d0a6b47535 (patch) | |
| tree | e32c70445ff409cf6cc7b8a8d4c263c95f3a9cc9 /apps | |
| parent | d4c6c11df0cf60dd956fe0d84f2edc97ffc8381d (diff) | |
| download | kukuri-main.tar.gz kukuri-main.tar.bz2 kukuri-main.zip | |
Three attempts at this and the cause was never the offset arithmetic. Measured
on build 86, the label mean angles were 45.9 / 130.3 / 209.1 / 319.9 degrees while
the wedge centres are 0 / 90 / 180 / 270. A constant ~45 degree error in all four
quadrants is not a magnitude problem, it is an origin problem.
The wedges are drawn at angles[i], which distributeAngles() fills starting from 0
and stepping clockwise, so item 0 sits at drawAngle 0 -- to the RIGHT, because
canvas angles run from 3 o'clock. The label loop was computing
`i * (360.0/n) - 90.0`, which assumes the first wedge is at the top. So the labels
were anchored a quarter turn away from the wedges, which is exactly one
separator, and no value of the constant would have fixed it.
The labels now take the wedge angles as a parameter and use angles[i] directly,
so a label and its wedge cannot disagree again -- including for a menu whose item
count is not 4 or which pins an item with an explicit `angle`.
Also worth recording: the two earlier attempts were tuning a constant while the
constant itself was wrong, and the measurements (19 px in the top quadrant, then
"all four on the boundaries") were consistent with an origin bug the whole time.
Diffstat (limited to 'apps')
0 files changed, 0 insertions, 0 deletions
