is there a way to “move” an operator to a different path, and therefore making the process faster (i.e. as when you move a folder in the same disk drive, much much faster than copying it then removing it)
On that same note, I’m basically trying to speed up the creation/settings of button based menus. I’ve tried - for each menu - creating them and whenever the menu change, instead of deleting all the buttons and re-creting them with different values, just resetting the values and turning off the ones I’m not using (or add more if I need to) but there’s a bug which I’ve reported about refreshing the UI - so for now I can’t use that method.
The question above comes from the idea of having a “pool” of button widgets that I can just move around my hierarchy as needed (i.e. for popup menus, etc) instead of having each menu instance create their buttons every time the menu changes.
For a few nodes, a fair comparison to windows filesystem copy vs. move would be a small file (2-5K or so), which takes just as long t copy as it does to move (instant).
The real cost of creating/deleting nodes isn’t the ‘copying’ operation, its gracefully disconnecting/connecting them to all of their dependencies.
Its possible an opmove would be beneficial in moving a large complex UI if it’s self contained, but it wouldn’t help with a few nodes.
So I’d expect further speedups to opcp and better recycling of memory will be the answer to this problem.
actually an opmove with a -I_swear_is_Self_contained flag could move hundrends of nodes in a flash, which is my problem now (it’s not a flash, not even close).
But of course swearing on that doesn’t mean its’ true… for example, how about the “path” flag - that’s the measure of my self-containment (internally it’s referenced a lot) - how about the clone field that’s cloning some widgets somewhere else?