Plug addition/removal should trigger dirty propagation

[danieldresser]

I'm fairly uncertain what exactly is going on here, feel free to rename this issue and add appropriate tags if you know the underlying cause and expected impact. I have a very simple test case:

1. Create a CustomOptions node
2. Select the scene inspector, so that there are no node editors visible
3. Run this in the script editor: script['CustomOptions']["options"].addOptionalMember( "name", "value", enabled = True )

This should result in a new option being visible in the globals section of the scene inspector, but it isn't until you manually force a refresh. Also, if you now go back to the node editor, and run it again, you won't receive any UI update for the second row on the node until you manually refresh. If you view the node editor from the start, then everything works fine.

I was wondering whether I need to call something special to force a refresh when using addOptionalMember, but this seems weird enough that there is probably something off? Calling setValue on one of the child plugs seems to consistently trigger a refresh, but that doesn't help if the change I need to update is that all the child plugs have been removed ( removeChild has the same problem as addOptionalMember ).

[johnhaddon]

What you're describing makes sense, and I think is best classified as a bug. Currently, setting a plug's value or connecting/disconnecting an input are the only two actions which trigger dirtiness propagation (which would then trigger the UI update you're missing).

I worked around this for the Outputs node, but that workaround won't work when removing a plug. What we really need to do is to propagate dirtiness following plug addition and removal. I'd like to see if we can avoid using signals/slots for this, since they do have a bit of an overhead (or at least we should measure that overhead and decide whether or not we want to pay it for every plug).

How high priority is this compared to everything else?

[danieldresser]

How high priority is this compared to everything else?

Hmm. I guess the effects of this aren't necessarily limited to the UI, it could affect actually computation?

Though, I guess I can work around it by setting enabled to False before removing plugs - I guess that probably works fine for my current use case, so not high priority.

[johnhaddon]

It won't affect computation, just dirty propagation. Dirtiness isn't a state like it is in some packages (this is necessary to be able to use multiple contexts and threads), it's just a signal that says "hey, anything you retrieved previously with getValue() is now potentially invalid" to observers of a plug. So the bug is that the UI doesn't update when it should, but when it does update, the compute will compute the right thing.