Unnecessary freedom to select the parameterization of the x-axis and y-axis.

[mlesnick]

Originally reported by: M L (GitHub: mlesnick)

---

One could argue that this extra freedom is user friendly. But it is not consistent with the description in the paper, and I find the way the barcode changes to be a little funny, and not consistent with our general visualization approach.

What exactly do we want here?

Should we have the bottom endpoint snap to the origin in this case? This seems more principled, though perhaps slightly more awkward from an interactivity perspective.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

One solution in between the two proposed extremes, is to keep the interactivity of the lower blue dot the same (so that it never skips down to the bottom left corner), but when the blue line becomes horizontal, have it extend all the way down to the corner, and have it plot the barcode taking \gamma(0)=0, so that as we slide the blue dot up and down the y-axis, the barcode doesn't change.

[mlesnick]

Original comment by Matthew Wright (GitHub: mlwright84):

---

Thanks for pointing this out.

I assume that the two lines you have selected in the screenshots above are exactly vertical -- i.e., the angle box (not shown) reads 90.000 degrees.

We could make the lower blue dot snap to the bottom-left corner of the box when the top dot is in the top-left corner (or the bottom-right corner), with the blue line extending all the way to the corner as well. This doesn't seem too hard to implement (but it might end up being harder than it seems), and as you say, it might be awkward for the user.

Making the blue line extend all the way to the corner without moving the lower blue dot would be harder to implement, because it would involve detaching the endpoints of the line from the blue dots. Currently, the endpoints of the line are always at the center of the blue dots. Changing this would involve modifying the C++ classes for the lines and dots, which is tricky -- these clickable objects respond to each other, and modifying one can produce unintended consequences for the others. Certainly it's possible to implement this solution, but it will take some work.

Still, even if we modify what happens for vertical lines, the user will always be able to approximate the behavior shown in the first screenshot above by selecting a nearly vertical line, such as a line at angle of 89.999 degrees, that appears vertical on the screen, and whose lower endpoint is in the middle of the left side of the box. However, such behavior for a non-vertical line is consistent with our description in the paper, while what can happen now for vertical lines is not consistent with the paper.