Allow arbitrary rotation of components

[nobody]

Parts should be rotatable in 15 degree increments so the Y and delta networks can be drawn correctly.

Part rotation is a very common operation therefore the user interface should be optimized for ease of use.
Now that redraw is seems fixed, r could be assigned to rotate 90 and R could be assigned to rotate 15.

[Peter Clifton (pcjc2)]

Moving this to feature requests.

Arbitrary rotations wouldn't be "that" hard to support, but would not be sufficient to allow what you request.

Since arbitrary (non multiple of 90 degree) rotation may land the pin coordinates off-grid, we would have to introduce snapping (and check connectivity still works) for off-grid pin-ends.

If we allow arbitrary rotation of all objects (which seems logical), we will have to think how we handle text which becomes rotated such that it would be "towards" the upside down position. gEDA has historically special cased text rotation, to flip the text back up the "right" way around as a component is rotated by 180 degrees. This rule will need generalising if text can take arbitrary angles.

(NB: Since the switch to cairo rendering, arbitrarly rotated text ought to "just work" once we remove the 90 degree angle input validation. I added the support for it (mostly requiring work on the bounding box checks) when writing the new rendering code).

[Krzysztof Kościuszkiewicz (k-kosciuszkiewicz)]

I have tested a patch to allow arbitrary rotations without snapping to grid - removal of 90 degree constraints would have to be accompanied by removing checks in file format.
Lines, arcs, nets, pins and text rotate OK.
Boxes need to be "upgraded" to paths to support arbitrary rotation - this is irreversible, so will have to be carefully considered.
Pictures would need support for rendering wiht arbitrary rotation.
As expected, after several rotations object will be moved off-grid.
Pin ends off grid are no longer marked as connectable, not sure about results of connectivity checks.

I would suggest to add support for arbitrary rotations with behavior depending on the "snap-to-grid" setting.
When snap to grid is on, resulting (x,y) object coordinates should be snapped after rotation. However this would destroy the looks of graphical elements (paths, lines already off grid).
Therefore second behavior could be triggerd with "snap-to-grid" being off - here no snapping of coordinates would be done.
But even in the second mode the rotation point should snap to grid - otherwise it is nearly impossible to obtain correct results.

One unsolved problem I can think of is rotation of components - should the pins/other objects inside be extended or not? I don't think so, but then connectivity needs to be revisited. What about text within the components? What about attached attributes?

If a sensible general policy cannot be developed, then at least few configurable options would have to be added.

[Peter Clifton (pcjc2)]

Just attaching what I had for text objects..

[Peter Clifton (pcjc2)]

I still stick by my earlier comments regarding snapping.

I wonder if rotating COMPLEX objects is sufficient, as that should cover the cases we need. Discrete lines / nets are more awkward, but could be accomodated by turning grid snapping off when drawing.

Perhaps allowing COMPLEX objects (as a kind of container) to be marked as rotated, we don't need to worry about converting the internals, such as boxes, pins etc..

As an alternative, people could of course make symbols for the off-orthogonal rotated version of resistors, inductors, capacitors etc..