Multiple rotations move asymmetric object from its original position

Anyone willing to guide me through the first steps for a proof-of-concept for this?

Thanks,
   Antonio

I've been strung by this bug, because rotating partial circles so they stay centered with circles below them is impossible with the current tools. This is pretty much broken (not wishlist) since creating transforms on circle elements where the origin (x, y) of the rotation is set to the center of the bounding box, makes animation and website rendering harder and more error prone.

It's not doing what users expect and it's not doing a good thing in to the svg output. We should fix it as a matter of greater urgency than wishlist.

I've added a feature to r15061, what it does is allows you to hold the Shift key as you drag the arc's start or end knots and it will move both start and end together. This is the equivalent of a rotation around it's center and may suffice for most users who have encountered this bug.

Thanks Martin. Also think is interesting the option for transforms pointed by the bug reporter, maybe as a optional method to preferences or a key modifier when transform, or double click to the center mark...

An event with the center mark is interesting and maybe an option is needed. Lock to center maybe.

My ui logic goes as follows:

* The arc nodes all work from the center of the circle, no matter what shape the resulting object.
 - Start and end knots (i.e. rotate)
 - height and width knots
* The selection tool nodes all work from the bounding box.
 - Rotate and skew handles
 - Height and width handles

So if we add a feature tot he selection tools to take note of the center of the circle, we should take care to make sure we don't make the tool do anything unexpected or inconsistent.

I coulden't reproduce the original bug report in trunk.
@martin. Its cool the selection tool detect a ellipse or circle and use his center instead bounding box center.

Maybe can be a preferences optional check if anyone dont want this behabiour

You want to do or put it on my TODO?

I think we can leave the option until we have some complaints.

I should say: We can leave the preference until we have some complaints, by all means make the center of the arc object the rotational center, I think it will be good. But only if it can happen without making the bbox or selection code complex.

Seems a easy change in my mind. But need to surf into to be sure.

Using the center of the "small enclosing circle" instead of the center of the "bounding box" as the center of rotation of any selection is the most general approach, but the code is not trivial especially if curves are involved, so a temporary workaround is welcome.

BTW, another way to make it easier to _manually_ set the center of rotation of arcs can rely on the patch proposed in https://bugs.launchpad.net/inkscape/+bug/481506 (please review) which adds an easy way to see the center, so an user could:

1. easily snap the center of the arc to the grid
2. snap the center of rotation of the selection tool to the same point on the grid
3. rotate

Antonio, I think current trunk don't need calculation of the small enclossing circle I try your steps
and rotation go well -from the final user point of view- now.

We only need to define the center repositioning the center origin from bounding box to circle/elipse center. Like you do in the patch but setting in the item inkscape:transform-center-x and y to this position.

Cheers, Jabier.

I think there is some confusion going on here.

The original report is not about the arc/ellipse object and its center.
I's about making multiple rotations "associative" by default for any asymmetric selection.

I added some confusion myself in comment #12 because I didn't fully understand what the comment in #2 was about.

The center of the "minimum enclosing circle" of an arc does not even coincide with the center of the arc.

So the current code in trunk solves the problem of rotating a partial arc around its center, I tested it and it works fine, but my report was not about that.

Example:
 1. convert an arc to a _path_
 2. Select the object and rotate it by 45 using the bounding box center (the current default behavior)
 3. Rotate it back by -45, the object is in a different position compared to 1.

My issue is not about rotational symmetry (which r15061 fixes), it's about associativity.

Thanks,
   Antonio

Thanks Antonio. I have also add some compexity :(
Yes this steps to reproduce are more clear to methan the ones in bug description. And yes the bug still present in trunk.

Maybe I should change the bug title.

What about something like: "Multiple rotations move asymmetric object from its original position", would that be clearer?

The current title suggests one possible solution rather then describing the problem.

Ciao,
   Antonio

Great idea. Also put this steps to reproduce in #14 could be useful.
Cheers, Jabier.

Anyway, could this fix become to undesirable result to users? Maybe we need to add this feature if done as a optional prefs. Seems good for ~CAD based drawings but for ~creative ones maybe is not the best.

Maybe we can finish the furthest time 2Geom work, I havent enoght math mind to finish myself:
https://github.com/jabiertxof/lib2geom/tree/furthestTime
Is mostly finished but there is things to finish. I think the code we need is done but need more to be merged on trunk.
Whith this you can do:
Furhhest time from center point1
Furthest time from point1 for point2
Nearest time from BBOX to point 3
Calculate the center of circle by 3 points.

The last thing to do is make working also in groups not only shapes or curves, for this maybe we can locate all centers of each curve/shape and make the center of small enclosing circle on it.
 This work need to be done in C++, for real use in UI transforms, extensions usaly are python code not in real flow.

BUt this is whath i do but remember maybe is not the best/efficient way to do.
Ping me if you need more help.