Add feature to replace nodes


#1

This is a summary of a discussion started in https://github.com/xodio/xod/issues/1635 by @donovaly. I’m moving it here because GitHub issues are for the backlog.

Problem

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)

#2

me:

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)

image

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.


#3

@donovaly

So, the issue poses more questions than answer

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.


#4

me:

:thinking: If it does not deal with the links, does it really helpful?

Compare:

Now

  1. Click to select a node
  2. Hit Backspace to delete it
  3. Double click to open the search

Then

  1. Right-click a node to pop the context menu
  2. Click the “Replace” item to open the search

Yes, it takes one step less, but should we sacrifice some other features to implement this one?


#5

Folks, what do you think about the node replacement?


#6

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.


#7

here I made the mistake of putting a personal node, RGB LCD I2C Adafruit 5 Button shield , which had to replace the same node of another library

The first solution was to edit the .xodp and place the location of the other library, but then include it in the project

A situation to replace the same node but from another location


#8

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).


#9

I agree is not a priority, edit full libraries from .xodp just changing the location or name.

I think someone who starts could put the new node, make the links and delete the previous one.

For the more advanced edit a .xopd with npp or another editor is very simple.