mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-13 10:04:13 +02:00
ispyisail
41e83bbc09
Raised by plc-user in discussion #618: the diagram editor allows moving elements by as little as 1px, and asked that rotation not undershoot that. Checking the actual constraint (Settings -> DiagramEditor_xGrid_sb / _yGrid_sb, both independently configurable, minimum 1, maximum 30) turned up a real, verified gap this PR's existing fractional-pivot fix doesn't cover: an ASYMMETRIC grid (xGrid != yGrid). Swapping X/Y deltas for a 90-degree turn -- the exact-arithmetic path already in this file -- only stays on the configured grid if xGrid == yGrid. With an asymmetric grid, a delta that was a clean multiple of xGrid lands on the Y axis after the swap, where the grid unit is yGrid, and one is not generally a multiple of the other. Verified on a real build (not just derived): two elements at (100,210) and (150,420), both on-grid under xGrid=10/yGrid=7, selected and group-rotated 90 degrees via a temporary local CLI harness. before this change: (242,292) and (32,342) -- off-grid on both axes after this change: (240,294) and ( 30,343) -- exactly on-grid Confirmed the same drift is present without this change too (i.e. not something introduced elsewhere) and that xGrid==yGrid, the common case, is unaffected: snapping an already-on-grid point is a no-op. Fix: re-snap the final computed position to Diagram::snapToGrid(), not just the shared pivot, for the exact-90-degree path. Left the arbitrary-angle trig fallback alone -- it has no caller today (the diagram editor only ever passes multiples of 90) and "on-grid" doesn't have a clean meaning for an arbitrary angle regardless of grid shape. Does not attempt to fix a separate, pre-existing property surfaced while testing this: four consecutive 90-degree turns do not reliably return a selection to its exact starting position, even on a symmetric grid, because each RotateSelectionCommand recomputes the pivot fresh from the selection's current sceneBoundingRect(), and an item whose bounding box isn't rotationally symmetric reports a different box (and therefore a different centre) at 0 and 90 degrees. Verified this drift is identical with and without this change, so it is not a regression -- just a different, harder guarantee this change does not attempt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>