#9277 NORM Not Tri: PolygonMorph

[Zarro Boogs per Child]

#9277: PolygonMorph
--------------------------------------+-------------------------------------
           Reporter:  amoreno         |       Owner:  etoys        
               Type:  defect          |      Status:  new          
           Priority:  normal          |   Milestone:  Not Triaged  
          Component:  etoys-activity  |     Version:  not specified
         Resolution:                  |    Keywords:               
        Next_action:  never set       |    Verified:  0            
Deployment_affected:                  |   Blockedby:               
           Blocking:                  |  
--------------------------------------+-------------------------------------

Comment(by ScottWallace):

 From Jerome Peace, 1 March 2009:

 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 :) .

 ------

 From Yoshiki, 2 March 2009:

  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?

 ------

 From Jerome, 2 March 2009:


 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?

-- 
Ticket URL: <http://dev.laptop.org/ticket/9277#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system