pcb-rnd knowledge pool
Copy/move/remove selected and unselected objects
| select_move by Tibor 'Igor2' Palinkas on 2018-04-15 | Tags: insight, select, selected, move, copy, refdes, subc, subcircuit, menu2file |
Abstract: Drag&drop move unselected objects behave differently than drag&drop move selected objects. This is not a bug, but decades old design decision. The selected-move mechanism also interacts with subcircuits. This article describes the mechanisms and some consequences.
User perspective
actions: object vs. selected
Any user input is eventually translated into an action . An action is a command, the same command the user can issue in the command line (either on the GUI, the ':' key, or in batch mode).
pcb-rnd GUI has multiple mechanisms for handling objects. Object actions operate on the "most visible" object under the mouse pointer , while selected actions operate on all objects selected. Many actions can operate on both object and selected , but there are actions that work only on either.
Move, copy, selected vs. unselected
A drag and drop (d&d) operation is an object operation if there is no selection. In this case, the preferred object under the cursor is moved. There may be multiple overlapping objects; the preference considers:
- layer visibility
- object type
- object size
- subcircuit parts are ignored unless they are floaters
In the object-mode move (or copy), no buffer is involved - single move (or copy) is an explicit operation implemented for each object type.
If there are selected objects, the move (or copy) changes from object operation to selected operation. Selected objects are cut (or copied) into the last paste buffer on drag and the buffer is pasted on drop. The last paste buffer is cleared after the operation.
If the control key is pressed while the d&d, the move becomes a copy, in both modes.
selected move/copy: subc parts
Because the selected move/copy operation is really a cut&paste through a buffer, it has different limitations than the object move/copy. For example if selection includes subcircuit parts, they are ignored for the move/copy operation - so that subc-locked objects (such as subc terminals) can not accidentally moved. Unlike with object move/copy, this does affect floaters as well. The most typical example is that a subc refdes text (which is normally a text object that is part of a subc and is flagged floater and dyntext) can not be moved when it is selected.
selected remove: subc parts
For the same reasons, the same rule applies: subc parts can not be removed through selected-remove, even if they are floaters.
Code perspective
Not being able to move/copy selected floaters may seem strange: floater means the object should ignore subc lock. It may seem like a good idea to allow it to be copied/moved to buffer. However, letting this happen would mean that parent subc information is lost - the floater (e.g. refdes text) is copied to the buffer, but the parent subc is not, so the new text object in the buffer has no way to remember it was a child of a subc on the original board.
Adding some kludge to track such parent relation was considered, but:
- what if the original parent subc is removed between copy and paste?
- what if you copy object between boards? the new board may not have the same subc, or even worse, with the same ID it may have a totally different subc.
The decision is that the whole system is cleaner if we do not make an exception for floaters. Which means selected subc parts, be them floaters or not, can not be removed or copied to the buffer.