There seems to be something fishy about assigning operations sometimes …
Here you can see how the connected operation is not inherited to new connected nodes in the graph, also selecting all and assigning as bulk doesn’t help.
One has to spot the unassigned links and select them individually …
So I guess the output pin is on the update operation within. Admittedly this bit is a little confusing for me but maybe the process node itself can’t be entirely linked to the to the member-method of another class?
That’s the state output of the internal backing field of the process node… It doesn’t belong to any operation, it’s the same as a pad in the patch. That’s why it doesn’t get a color. Should probably be drawn differently…
A process node can’t be assigned to an operation as it is made up of potentially many fragments. Assigning all fragments of the process node to the selected operation would just lead to other very confusing issues (we had that already in the past). Further the fragments of a process are not modeled as such in the patch, so the only way to assign them to different operations is through links. Now here comes the first issue, that when selecting multiple elements in a patch the links are NOT selected - I think there’s a shortcut to include them in the selection, but there was a reason why links are not part of it @tebjan or @joreg?
In any case, since they’re not part of the selection, nothing can be assigned.
Modeling the fragments explicitly in the patch wouldn’t help much either as you would suddendly be confronted with a multi question as each selected process node could come with a different set of fragments and you would need to decide what fragment of what process goes to the operation you wanna assign them to. Sooo we decided to keep it on the links, and the fragments will then pick that information up.
What maybe could be done is modifying the assign command, so inbetween links get picked up in that moment.
That the blue color (in your case) doesn’t get propagated further up is indeed caused by the special state outputs of the process nodes (no color). As already said, they must be thought of as pads (and not pins) as they represent the state which can always be looked at. And the color propagation (or flood fill as we call it internally) stops at pads.
So I agree situation as-is is not optimal, but didn’t come up with a good solution yet. Ideas are very welcome!
indeed links are not included in a selection by default. reason for this is that when making a rect-selection around some nodes to delete them, you often also include links that you don’t want to release. if you want to include links, press SPACE while making the selection.
another pending problem with link assignments: we’re still missing a visualization for them. so you can understand if a link is manually assigned or not.
But that doesn’t explain the IOBox towards the end of my gif that also ends in Update at first, no?
Also helping the user spot “off-color” links connected to a set of nodes already predominantly assigned to a different operation … so my original problem was a rather complex Skia based set of nodes for drawing something, and I just noticed that something didn’t work as intended until I finally spotted a gray link to an IObox by chance. Which I still don’t really feel was explained how that can happen in the first place.
Edit: or just highlighting links assigned to different operations connected to a mutual node/pad