mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
fa213d90d9
Split from #913's second suggestion. There was no shortcut for the common "duplicate with offset" convention; the nearest existing feature, "Collage multiple", is a different workflow (a dialog for repeating a paste in a grid pattern, not a one-shot duplicate). Ctrl+D copies the selection and places it immediately, offset by a configured spacing and direction -- no interactive follow-the-cursor step, unlike Ctrl+V. The first press (or after the setting is explicitly reopened) shows DuplicateOffsetDialog: spacing in grid steps, direction up/down/left/right. Every later press reuses whatever was confirmed then, silently, so a row of copies is one key held down and tapped, not a dialog every time -- unattended, repeatable stamping is the actual point of a duplicate shortcut, which a dialog or an interactive placement step on every press would defeat. A separate "Configurer la duplication..." entry reopens the dialog on demand to change the setting later. Cancel leaves the diagram untouched -- verified, not assumed: qet_diff against the saved file shows 0 added. Chaining ("keep tapping to lay out a row") needs no special handling: QET already reselects whatever a paste just added (PasteDiagramCommand::redo()), so the next Ctrl+D naturally continues from the copy just placed rather than the original. The offset is applied by hand rather than by asking paste()/fromXml() to place the copy at a target position. Both of those feed the position through Diagram::snapToGrid(), which reads QApplication::keyboardModifiers() and rounds to the nearest PIXEL instead of the grid whenever Ctrl is held -- and Ctrl is always held here, this action's own shortcut being Ctrl+D. Measured before settling on this: routing the offset through paste() first produced copies off-grid on both axes, by an amount that tracked the selection's own bounding-box geometry rather than being a fixed error -- caught by qet-mcp's qet_elements against the saved file, not by eye. fromXml() is instead called with no position argument at all (leaves every item at its source coordinates, landing the copy on top of the originals -- (0,0) is not a position, this is "keep the source coordinates"), and the offset is added directly with setPos(). A plain addition cannot be off by a rounding rule that never runs. Conductors are not in the hand-translated set: fromXml() itself does not reposition them either -- they load after elements are already in their final place and take their geometry from their terminals, which have already moved with the elements that own them. Verified this holds: drew a conductor by hand between two elements (drag, not click-click), selected both, Ctrl+D, and the new conductor correctly joins the two new elements via qet_conductors -- not the originals, not a mix. Verified end-to-end on a built binary via qet-mcp, not by eye: before L2 (303,207) L9 (512,196) -- deliberately off-grid spacing=2, down (303,227) (512,216) -- +0,+20 exactly same again, 2nd (303,247) (512,236) -- +0,+20 again, chained Both elements land exactly the configured offset from their immediate source regardless of the selection's own alignment. Qt 6.10.2, ctest 11/11. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>