chenbo007 / svg-edit

Automatically exported from code.google.com/p/svg-edit
0 stars 0 forks source link

Dragging poly point grips does not work correctly when poly is rotated #93

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Click the Poly tool, draw a poly and close it
2. Select the poly, rotate it 30 degrees
3. Click on the poly again in Select mode to go into PolyEdit mode

What is the expected output? What do you see instead?
The poly point grips are not rotated and aligned with the rotated poly.

Original issue reported on code.google.com by codedr...@gmail.com on 17 Aug 2009 at 3:59

GoogleCodeExporter commented 9 years ago
This one is proving to be quite tricky. It's easy enough to set the
pointGripContainer to be rotated like the poly, which puts the poly point grips 
in
the right place. But the problem after that is that the points are displaced 
from the
cursor position whenever you try to drag them.

Still looking into it, but if anyone has any suggestions on how to tackle it 
that'd
be great.

Original comment by adeve...@gmail.com on 18 Aug 2009 at 3:57

GoogleCodeExporter commented 9 years ago
I agree - this one is tricky.

I think what you're saying is you tried to set the transform on the
pointGripContainer and rotate the whole <g>.  I agree, this will be problematic
because people are still dragging in an axis-aligned perspective so I'm not 
sure what
that would do to the drag tracking math.  

It sounds like if you did this, then you could do some trig math in the 
mousemove
function when in polyedit mode to convert the dx,dy into the rotated dx,dy - I
haven't found the time to spend on this one because it's involved.

The only other thing I can think of to fix this is to figure out the rotation 
math
and then manually change the coordinates of each point grip in the container.  
But
actually, will that help?  You'd still have the dragging math problem I think.

I suppose you could always check in what you've done so far and we can try to 
figure
out the math afterwards - this would only break poly edit mode for rotated 
polys -
and that's already broken anyway! :)

Original comment by codedr...@gmail.com on 18 Aug 2009 at 4:03

GoogleCodeExporter commented 9 years ago
Changed the summary to describe the remaining problem.

Original comment by adeve...@gmail.com on 18 Aug 2009 at 8:01

GoogleCodeExporter commented 9 years ago

Original comment by codedr...@gmail.com on 18 Aug 2009 at 8:03

GoogleCodeExporter commented 9 years ago
Ok, I figured out what the problem is - but I'm not yet sure how to solve it.  
I've
checked in my work-in-progress code as r413.

First, some background:

- the rotate feature currently works by figuring out the center of the shape's
bounding box and then rotating the shape a number of degrees around this center
- so a shape could get the transform="rotate(35,200,100)" if the user rotated 
it 35
degrees
- if the user then tries to change the shape's size (or shape in the polyedit 
case),
this actually affects the bounding box (and thus, its center)

What I've done in my code is figure out what the original rotation center is
(200,100) in my example above by parsing the transform attribute.  Then I 
determine
the ray from this center to the poly point that I'm dragging.  Then I rotate 
this ray
into the element's rotated coordinate system.  Then I modify the x,y mouse
coordinates by this transform so that the poly point is dragged to the mouse 
location.

This works great.

Unfortunately, it breaks subsequent rotations after you've moved a rotated poly 
point! :(

So I'm still thinking of the 'right' way to solve this.  This is the tenet that 
I'm
working from:

- if a user rotates a shape 30 degrees, that shape stays rotated 30 degrees 
(even if
they later resize or move the poly's points around)

Original comment by codedr...@gmail.com on 19 Aug 2009 at 3:49

GoogleCodeExporter commented 9 years ago

Original comment by codedr...@gmail.com on 19 Aug 2009 at 2:31

GoogleCodeExporter commented 9 years ago
This is again seriously broken.  I may tackle this as part of the experimental
rotator branch.

Original comment by codedr...@gmail.com on 20 Aug 2009 at 6:25

GoogleCodeExporter commented 9 years ago
Finally seem to have solved the math issues in 471.  You can:

- edit points in a rotated poly
- resize rotated elements
- translate rotated elements

without unexpected results.  Problems can be opened as new issues.

Original comment by codedr...@gmail.com on 26 Aug 2009 at 5:08