element standard id sequence #83
Labels
No labels
bug
design
duplicate
enhancement
maintenance
prospective
question
regression
stub
todo
ui
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: StudioInfinity/dyna3#83
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Although this is relatively low priority, right now when an element id is not specified, it get assigned from either the sequences point1, point2, ... or sphere1, sphere2, ... . But these are not the typical identifiers used for points and spheres in a geometric construction: more commonly one would see A,B,C,... for points and maybe s,t,u,... for spheres. We should switch to id assignments that will feel more "natural" in this respect. However, there are some traps that GeoGebra falls into in this regard that we need to avoid. For large numbers of points, their A,B,C... sequence goes U, V, W, A_1, B_1, C_1, and eventually to W_1, A_2, B_2, and then their default sort order ends up with A, A_1, A_2, B, B_1, B_2, C, C_1, C_2,... so that points of very different "ages" and hence likely unrelated end up adjacent in the "outline view", making the logical structure of the construction hard to perceive. We need to make sure default order is "age-related," and ideally also have the default identifiers mesh with that "age" order, without just resorting to P_0, P_1, P_2, from the beginning, as making everything just P with a subscript is confusing in its own way. Similar comments go for other element sorts.
Specifically on point IDs, I don't know if I have an ideal suggestion at the moment -- maybe it's something like A, B, C, D, E, F, G, H, I, J, K, L, M, N, P_1, P_2, P_3.... ??