This PR is against RB-2.4, but will be merged in RB-2.5 ultimately.
fixes #732 (this bug has been here forever)
Explanation: the nodes are not deleted while they're still in the Undo stack (which has a depth of 20 actions by default). You'll notice that if you do 20 actions (move 20 times a node in the graph), you will be able to do that rename.
I have a proposed change, which allows using the name of an existing deactivated node. To reactivate the deactivated node, the name change would be reverted by RenameNodeUndoRedoCommand::undo() anyway.
I had to add a few checks in the code:
I had to make sure that every use of Node::getScriptName_mt_safe() (except for printing messages) was also checking if the node was activated.
This seems to work.
@rodlie @YakoYakoYokuYoku Please decline the review if you think you can't review
This PR is against RB-2.4, but will be merged in RB-2.5 ultimately.
fixes #732 (this bug has been here forever)
Explanation: the nodes are not deleted while they're still in the Undo stack (which has a depth of 20 actions by default). You'll notice that if you do 20 actions (move 20 times a node in the graph), you will be able to do that rename.
I have a proposed change, which allows using the name of an existing deactivated node. To reactivate the deactivated node, the name change would be reverted by RenameNodeUndoRedoCommand::undo() anyway.
I had to add a few checks in the code: I had to make sure that every use of Node::getScriptName_mt_safe() (except for printing messages) was also checking if the node was activated.
This seems to work.
@rodlie @YakoYakoYokuYoku Please decline the review if you think you can't review