fixed ratio resize

[GoogleCodeExporter]

since the addition of paths it becomes very important to be able to resize
keeping the same ratio between height and width. better yet: when you click
a control point the application should add on the toolbar additional
formfields:

magnify ratio, x position of the point, y position of the point, and a
checkbox: fixed ratio (you want a resize/modify by coordinations' change or
a fixed-ratio resize of the whole object)

(for the corner control points o on object these fields should be even more
numerous: accounting for usecases of shear and rotate (where will we have
enough room for those??))

Original issue reported on code.google.com by Christia...@gmail.com on 13 Aug 2009 at 9:17

[GoogleCodeExporter]

Christian,

I agree with the things you state - let's keep this bug for fixed ratio 
resizing (how
does shift-dragging sound?)

I don't quite get the other thing you mention (checkbox and magnify ratio), but 
can
you open another bug for contextual tools for control points:

- x,y values of point
- delete button (to delete a control point)
- clone button (to create a new point maybe)?

Thanks,
Jeff

Original comment by codedr...@gmail.com on 13 Aug 2009 at 12:09

• Changed state: Accepted
• Added labels: NeededFor-2.4

[GoogleCodeExporter]

"control points" - i was referring at those points that you have on the margins 
of
the objects' confining rectangle. "path points" or "path nodes" would be those 
that
determine the nodes of the path. i'll open another bug now about control points

Original comment by Christia...@gmail.com on 13 Aug 2009 at 12:30

[GoogleCodeExporter]

yes, shift-dragging would be the intuitive way of approaching fixed-ratio resize

Original comment by Christia...@gmail.com on 13 Aug 2009 at 12:55

[GoogleCodeExporter]

So how hard would this be to achieve?  If shift is down before starting to drag 
a
resize node, then lock the aspect ratio of the thing being resized:

 * ratio = width/height (need to be careful of divide-by-zero)
 * the scale() transform needs only have one number (either sx, sy depending on
whichever is larger perhaps?)

Original comment by codedr...@gmail.com on 13 Oct 2009 at 4:02

[GoogleCodeExporter]

A very simple fix for this was made in r942, seems to work as expected to me. 
There 
is currently a problem with inverted resizing, but it wasn't caused by this.

If this works as expected to others, feel free to close the issue.

Original comment by adeve...@gmail.com on 13 Nov 2009 at 3:15

• Changed state: Started

[GoogleCodeExporter]

Original comment by adeve...@gmail.com on 16 Nov 2009 at 9:34

• Changed state: Fixed