A common task is to replace nodes by another one. Take for example the mapping node. In many cases you later see that you need to replace it with the map-clip node.
Solution
add the following feature:
right click on a node and select in an appearing context menu “replace”
this will open the search nodes dialog and you can search for a node you like
after selecting a node and pressing Return the selected node will replace the existing one
links to the former node will automatically be removed
(- if possible links to inputs/outputs whose name and type is identic to the former node could stay)
Thanks for the feedback. I see the problem, but can’t agree with the solution.
Asking to do a new search for a replacement is excessive for the most common substitutions. It could be done with the drop-down in the Inspector (under node name)
The list could be populated automatically. But the concrete algorithm should be carefully thought: full match by pins, full match by pin types, strict superset by pins, whatever?
Another way to think about is having an ability to replace an existing node with another already existing node on a patch. Some tricky mechanism to drag-n-drop.
Yet other way is your proposal supported by the new special syntax in the search bar. Something like ”replaces:xod/core/map foo bar baz” which will look for “foo bar baz” but only among nodes suitable to replace xod/core/map.
Please let’s keep it simple! I described the implementation of LabView and it works there very well and saves a lot of time. There is no need to make it that complicated to keep links. Just replace it by the desired node, cutting off/deleting all existing links to the existing/former node is fine.
Hmm, I see that your solution leads to what one needs - a replacement to the same position. So a real replacement feature would only make sense if some links would be kept alive. I think that is too much for XOD for now.
I see how it could be useful occasionally, but I don’t see it as an important feature that should be higher priority than what maintainers are already working on. Especially if existing links are just going to get dropped; how is that so much better than delete/add?
If you are going to try to keep existing links, there are so many ways that could be said to be “right”, how do you choose which to code? If pins don’t need the same name (only judge by type), how do you determine if order should be changed? What about pins that allow multiple types? Unless you force pin-name match, you are just asking for introduction of bugs in your code using it.
Even if you use pin-name, do all pins need to match, or do you keep links for pins that match & drop other links? If you are dropping some links, should there be some way to flag the dropped links to make it obvious they need resolved (perhaps keep them, but flag them as errors; what if replacement node has fewer pins)?
I guess you could eliminate much of the confusion if you only allow replacement with nodes that have matching pins (by name, or by type? By type adds risk since order of pins might change in replacement), perhaps allowing replacement to have additional pins for added functionality (adding even more risk if you only match by type).
If it does not deal with the links, does it really helpful?