I’m currently working on a component that observes child-behaviuor in a component.
I check if operators get created or deleted.
I hold a refference to an deleted-operator in my extensions so I still have a ref to the operator when it is deleted. But I can no longer get any information out of it as it is, of course deleted (still getting path and name though, so thats nice).
Is there any way to keep an OP alive (or bring it back to live) to at least get stuff like params out of them?
If you also held onto the operator type you could bring it back… minus the state of the pars when deleted.
hmmm… though it does look like you’d also loose connections as well.
I guess this depends a bit on how many ops you’re watching… but you could keep a cold clone of the target op in a hidden portion of the network. I don’t know if this idea would totally work, but off the top of my head I’m thinking about a clone of your target whose cook flag is turned off, and whose clone par is either pulsed or active / inactive at the discretion of your extension. I guess the big idea here is that you could keep that cold clone one state behind your target, then revert / extract pars and ops if you found that ops were destroyed in the target.
Hmmm, having a cold-clone was something I thougt about too, but something feels iffy about that, even with cooking disabled this could create some unwated behaviour, but might still be worth a try.
Only prolem will be that I cannot catch the changes of params in time as I would only be able to pulse the cloning after a new operator gets created or deleted, and not in between. So when the user updates any params they will to propagate to the cold clone. I was also thinking about creating a pickle of the operator in localStorage, but this basicly holds the same problem of 2 sources of truth.
I was hoping of something like that operators only get completly removed from store after the frame ended. Maybe something in the direction of a graveyard python-object that holds on to operators for the rest of the frame?
That makes sense - your graveyard could hold the state from the previous change, and then return to it if needed.
It’d get messy, but you could also keep a record of all created ops and their connections (and if they’re deleted). That’s a lot of book keeping… but you could probably use some rules where a parent is only responsible for 1 layer of depth’s worth of records. You’d probably want handles on if you track par changes, or only op additions / subtractions.
There’s also the undo class - maybe there’s something there to think about.
Oh, the UndoClass. I totaly forgot about that.
As it is right now it seems to not be of a direct help, but this means that there must exist some kind of graveyard for the undoFunctionality to replace deleted operators. I will dig deeper into that.
Keeping track of the complete network (or just single comp) seems totaly overkill for me in this situation as there is so much stuff to keep track of, and with the opExecute being somewhat borked atm this might be little bit complicated.
I will report on findings in regard to the lead of Undo.
Edit: No findings so far and going back to other stuff. Digging in /sys I found that the cut and copy-buffer utilize this, but this specific point is not where they get cut to.
So, the question is
Where do OPs go to die?