Well, it’s a bit more than just a function... What I’ve done previously is to attach a hidden text knob to each Grizmo, with a consistent name, whose value holds the custom class (including version). The other part of it is a Python class that manages callback registration for the different Nuke slots, one level removed from Nuke’s per-class callbacks.
Then I just add a callback function in each Nuke callback slot that operates on a node class, set to operate on Groups. It basically loops through the Group nodes in the script, tests for the hidden class knob, and if it is found, passes that knob’s value and the name of the currently executing callback slot through to the management class to check for registrations matching those criteria and call them accordingly. -Nathan From: sh4dow Sent: Tuesday, September 04, 2012 12:48 AM To: [email protected] Subject: [Nuke-python] Re: Assigning a custom nodeclass to a gizmo? Diogo Girondi wrote: Managing revisions and versions of grizmos in scripts that are being versioned themselves can quickly become a real nightmare. Well but what about opening an old comp that uses a gizmo that has been changed? An artist should always be able to rely on the fact that whatever he used in the comp still works as it did back when he first created it. And of course not every little gizmo people create may make it to a company's repository right away, in which case grizmos help should it be necessary for a different artist to edit a comp. @ NathanR: So what function can be used to change class names? -------------------------------------------------------------------------------- _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
