Hi Yoshiki & crew
Attached are some repairs for handles that prevent the errors antonio ran into. These are essentially from my polygon work for 3.9/3.10.2. They leave out the curvier repairs and just focus on the handle repairs.
I also noticed that arrow prototypes and triangles allow for deleting vertices but then prevent anyone from adding vertices back. So when you get a polygon with just one vertex it will be forced to stay that way.
This is not a problem for closed polygons except for triangle prototypes which aquire a special property to prevent additions. It is a problem for polygons that are open.
So I modified addHandles to allow a triangle handle for one vertex polygons. I also modified setVertices: to remove the special property when any polygon gets down to one vertex. That seem to me less limiting that the current case.
Looking at triangles and how simple and elegant they look with handles, it seems to be it might be nice to give the users a choice whether to have the triangle handles show or not. A second menu item perhaps
show move handles show edit handles
(with the check boxes in front as you do now).
It might even be pleasant if the move handles refrained from deleting themselves if the edit handles were not present. Then triangles would stay triangles etc.
That was too much of an enhancement to force on these repairs, but the thought has now come up :) .
Yours in curiosity and service, --Jerome Peace
Thanks, Jerome,
In the meantime (ah this happened again), Hayashi-san had another proposed fix that looks like attached. This is really the minimum fix and easier to adapt I consider, but what is your opinion?
-- Yoshiki
Hi Yoshiki,
Hayashi-san works fast! :) I have downloaded his fix and will play with it soon.
Hayashi-san's fix seems to address other code than my fixes. Other than updateHandles (and setVertices: ) they don't seem to collide. So my general recommendation would be to combine both.
His fix does not address the ungrowable one vertex problem which would be considered a separate bug from what antonio reported.
Also having a factored out midPoints method gives a lot of useful options going forward. You could create a polygon from just the midPoints for example.
The tests hasArrows and isCurvy are also frequently needed and factoring them out simplifies code and reduces bugs.
When a curve is down to two points isCurvy recognizes that there is no reason to use the curve calculations. This benefits a little bit in terms of speed and it also helps proper placement of the midpoints.
The code I sent you has been in use in 3.9 and 3.10.2 so I have some confidence in it being solid.
What are Hayashi-san's thoughts?
Yours in curiosity and service, --Jerome Peace
--- On Mon, 3/2/09, Yoshiki Ohshima yoshiki@vpri.org wrote:
From: Yoshiki Ohshima yoshiki@vpri.org Subject: Re: [Etoys] repairs for one vertex polygons To: etoys@lists.laptop.org Date: Monday, March 2, 2009, 3:35 PM Thanks, Jerome,
In the meantime (ah this happened again), Hayashi-san had another proposed fix that looks like attached. This is really the minimum fix and easier to adapt I consider, but what is your opinion?
-- Yoshiki
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
etoys-dev@lists.squeakfoundation.org