[Bf-committers] (no subject)

[Lukas Tönne]

In the current node editor workflow there is no good way of moving
nodes between different node trees. Nodes can be duplicated in a node
tree, but not easily transferred to a different tree data block.

While it would have been a nice feature in earlier Blender versions,
the lack of it was not really a showstopper, since all node editing
basically worked in the same node tree. The only exception would be
editing node groups, but inputs and outputs were generated fully
automatic (and pretty much useless), so it was possible to just
destroy and recreate a group to include nodes from the parent node
tree (even though this means piling up old unused group data blocks).

Now the interface for node groups is much more controllable (custom
socket names, internal links) at the expense of requiring some more
work by the user, so simply creating a new node group data block every
time you want to add nodes seems stupid. A good workflow for moving
nodes between a parent tree and node groups becomes imperative, even
more so when thinking about the future (groups inside groups, more
customizable interfaces).

My first attempt at creating such a feature was to implement
copy/paste operators, similar to what you find in other software for
duplicating/moving data between different parts of the program (code
review here [1]). While it works for simple cases, there are a number
of problems that are not easily solved:

* Animation data would have to be extracted for just the copied nodes,
then stored in an "clipboard" buffer and inserted+remapped in a
different ID block later. Could work in principle, but might have ugly
corner cases and no precedence in Blender so far.
* Pointers in the node data would have to make sure the user count is
handled correctly (clipboard should not increase user count), and must
check for existing data blocks on insertion into other trees.

It seems that this approach has too many risks of losing data and is
generally not "The Blender Way (tm)". So here is my suggestion for an
improved method that follows existing patterns:

1) For inserting into existing groups: extension of the "make group"
operator (ctrl+g)
    The operator would show a selection popup like the parenting
operator, with options depending on the type of the active node (last
selected):
    * "Make new group" -> regular operator, creates new group type
with all selected nodes inside. Currently still prohibits groups
inside groups, but that is technically possible now, so should be
allowed.
    * If active node is a group: "Add to group" -> adds all other
selected nodes into the group (exception: one of the selected nodes is
of same group type as active node (or contains it on deeper level).
Recursive grouping is still impossible.)

2) For extracting from an existing group: Add a "separate from group"
operator (p ?)
    Works similar to separating vertices/edges/faces from mesh (p).
This will move the selected nodes from the currently edited node group
to the parent tree. This could also have two options in a selection
popup if needed:
    * "Copy" makes a copy of the nodes in the parent tree, but keeps
the original group intact. Note that the "ungroup" operator works
similarly: it makes a copy of all nodes in the group and removes the
instance, but does not actually change the node group itself.
    * "Separate" will remove them from the node group. Any connection
to unselected nodes is removed!
    * "Separate with interface" will remove from the node group and
add new interface sockets for broken links. These can then be
fine-tuned afterward with meaningful names, etc.

The introduction of popup selections to specify operator modes is an
additional step in the workflow, but since these operators are not
executed very frequently i think they are justified. They help to keep
the number of direct keyboard shortcuts needed to a minimum.

After executing any of these operators the editor should switch to the
"target" node tree (where copied nodes are placed) to allow quick
placement of those nodes.

Note that this method still does not provide a good way of directly
moving nodes between unrelated node tree data blocks, only between
node groups and respective parent trees. I think this is an acceptable
limitation as sharing nodes between different trees would usually make
use of node groups anyway. If necessary an intermediate group could
even be used as a "clipboard" for transferring nodes this way -
clumsy, but avoids the problems of direct copy/paste.

Let me know what you think.

Cheers,
Lukas

[1]
http://codereview.appspot.com/6249060/