Problem summary: knobChanged callbacks on Gizmos can execute during script load/node creation
Customer reported version: Nuke 16.0v4
Customer reported platform: Windows N/A
Steps to reproduce: 1) Launch Nuke and paste the following Group into the Node Graph:
Group { name Group1 knobChanged "print(f'\{nuke.thisNode().name()\} - \{nuke.thisKnob().name()\}')" selected true xpos 1052 ypos -48} Input { inputs 0 name Input1 xpos 0 } Output { name Output1 xpos 0 ypos 300 }end_group
2) Open the Group's Properties, and press the export as gizmo... button 3) Create a Gizmo in the ~/.nuke folder named "knob_changed.gizmo", or similar 4) In the Node Graph, press the X key and enter the name of the gizmo ("knob_changed" in this example) 5) Optionally, make some adjustments to the Gizmo's knobs, such as adding a label and enabling the bookmark and postage_stamp knobs 6) Navigate to File > Save Comp As... and save the .nk script, then use File > Clear 7) Open the Script Editor and clear any existing lines 8) Open the file saved in step 6 and observe how the Gizmo's knobChanged callback is executed while the Group's is not:
Expected behavior: knobChanged callbacks should be executed when the value of a knob changes, not when a node is created.
Actual behavior: knobChanged callbacks attached to Gizmo nodes can be triggered during the node's creation, even though the knob values are not changing.
The same behavior also occurs when Gizmos with a knobChanged callback are Copy/Pasted into the Node Graph.
Workaround: No known workaround at this time.
Reproduced by Support in: Nuke 16.0v6 - Windows 11, macOS 14 Sonoma Nuke 15.0v1 - Windows 11 Nuke 14.0v1 - Windows 11 Nuke 13.0v1 - Windows 11
Earliest version tested: Nuke 13.0v1 - This issue appears to be in all tested versions of the product