Copy-pasted nodes should not be placed perfectly on top of the copy
For example if you want to duplicate some nodes (shader editor) you select them and then press control-c and then control-v. This pastes the copy but it places it perfectly on top of the original copy. This can be misleading or weird for the user as at first look it may look like nothing happened. Only if the user then tries to move the nodes he sees the paste operation did actually duplicate the nodes. (When I first tried copy-paste myself I thought it did not work). In a complex scene you can also accidentally press control-v twice and you have 3 sets of nodes while you think you have 2 sets because they are all top of each other. This is a pain to clean up later.
Solution. When nodes are (copy)pasted in shader editor moves the pasted nodes to right and down something like 10 pixels. This makes the paste operation provide visual feedback when it happens and also gives the user information that the paste operation worked and how many times he did it. And it separates the nodes so you can move them easily and move the right ones.
8 Comments
YES ! Visual feedback on Paste operation in this particular editor is a must ! This is different from the 3D view where it is often normal to have a duplicate of an existing object at the same place.
Why not just use Duplicate <kbd>Shift</kbd>+<kbd>D</kbd>? When it duplicates your selection, you immediately get the ability to move it where you'd like.
@Jason van Gumster: I'm not looking for a workaround but simply posting an improvement suggestion.
Copy-paste as a tool is more useful with nodes compared to shift-d as it can copy nodes between different materials as well. But even then what you said highlights another issue. Why does shift-d and control-v behave differently? Why does shift-d give movable selection as a result but copy paste doesn't?
@o7216059: It's not a work-around. It's the right tool for the job. You want to use <kbd>Shift</kbd>+<kbd>D</kbd> because you're immediately duplicating in the same space, so it makes sense to have the duplicates in a different location. Copying and pasting is not something to use in the same space. I often take advantage of the fact that copying and pasting puts nodes in exactly the same spot when copying them between scenes or files. I find it useful and helpful. So, for me, what you're describing as a pain point is a beneficial feature.
@Jason van Gumster: I really don't want to argue whether it is a workaround or not.
I am not saying the pasted nodes need to be moved if you copy them to different material. I am saying if you use copy-paste to duplicate a set of nodes inside one material it should not paste them directly over the copy in that situation because it is confusing and poor ui design. I'm sure you agree that in that scenario it is not a beneficial feature?
That being said whether you use copy-paste or duplicate the pasted nodes... the nodes should be movable by default in both cases after the operation. In that case you'd not even need to move anything when pasteing or even check if there is an overlap problem. Which makes this discussion somewhat irrelevant because the original issue is that duplicated nodes are selected and movable after the operation but copy pasted nodes are not.
@o7216059: To be fair, pasted nodes are already selected. Once you paste, you can move the whole bunch by pressing <kbd>G</kbd>.
@Jason van Gumster:
But the behavior is still different between shift-d and ctrl-v as one gives movable selection but other just a selection. Both should give a movable selection. At the cursor.
@o7216059: I completely disagree. I rely on having paste putting objects and nodes exactly where they were.