Gotcha, thanks Matt. I will try it. I assumed it would have the same problem where the node is changed to the values stored in the Preferences file if the user opens prefs and hits Cancel - but I'll try it and let you know if I run into any trouble. It is definitely better than my current trick of forcing a preferences write.
Den On Wednesday, August 26, 2015, Matt Plec <[email protected]> wrote: > Hey Den - > > There is a formal way to set default knob values: a knobDefault command at > startup. I expected that to do what you're after. It's just that it doesn't > seem to work on the preferences node. > > However the prefs node is a little special -- it needs to load knob > settings from your ~/.nuke prefs file at startup. Maybe there's something > buggy in the way that's interacting with knob default settings. I'm not at > the foundry any more so I can't check the bug tracker or dig around in the > code but I would be surprised if it hasn't come up before. Out of curiosity > I just sent an email to support. I'll post back here if I hear back > anything worth adding. > > The autoSaveFilter Ben suggested handles more complex cases of autosave > but could be used to work around the knob default not working for this > case. But for the prefs node knobs in general the workaround I suggested > should do the job. I'm not sure why you think it won't stick. The value is > forced in at startup and again any time the knob is changed (which is what > works around the panel cancel reverting it). It overrides whatever's in my > preferences9.0.nk file, too. I was testing in 9.0v6 NC with the > AutoSaveTime knob, though, so YMMV. Give it a try before you dismiss it. If > it works for you, you can at least get everything in your init.py and not > need the other save prefs hack you mentioned. It will prevent users being > able to set that pref themselves, though. > > Matt > > > On Tue, Aug 25, 2015 at 11:16 PM, Den Serras <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Thanks Ben and Matt! >> >> It amazes me that there isn't a more formal way to do this. I think if I >> use your method, Matt, I'd still have the same issue with my initial >> changes not sticking. I've already disabled the knobs I don't want them to >> mess with, so I'm less worried about that. It just seems like either >> there's a formal system for this that I'm totally missing or I'm >> accomplishing it all wrong. Ben's suggestion handles the autosave problem >> but there's lots of others that need fixing. >> >> I'm just surprised that hacking a save to the preferences or changing it >> back with a callback really is the solution The Foundry envisioned for >> studio-wide preferences. >> >> Thanks! >> Den >> >> >> >> >> >> On Monday, August 24, 2015, Matt Plec <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> For other knobs, like the autosave time, you could set a knob changed >>> callback to reset the value to what you want whenever it gets changed, >>> which seems to catch that prefs panel cancel resetting it. You might also >>> want to disable it so users don't get frustrated trying to set it to >>> something themselves. Try this in init.py (using 9.0v6, ): >>> >>> nuke.toNode('preferences')['AutoSaveTime'].setValue(33) >>> nuke.toNode('preferences')['AutoSaveTime'].setEnabled(False) >>> >>> def fixPrefs(): >>> k = nuke.thisKnob() >>> if (k.name() == 'AutoSaveTime'): >>> print 'fixing AutoSaveTime' >>> k.setValue(33) >>> >>> nuke.addKnobChanged(fixPrefs, nodeClass="Preferences") >>> >>> >>> >>> On Tue, Aug 25, 2015 at 8:42 AM, Ben Dickson <[email protected]> >>> wrote: >>> >>>> This should be doable with the nuke.addAutoSaveFilter callback >>>> >>>> >>>> http://docs.thefoundry.co.uk/nuke/80/pythondevguide/callbacks.html#autosavefilter >>>> >>>> >>>> On 25/08/15 11:56, Den Serras wrote: >>>> >>>>> I wonder if I'm going about this all wrong, considering the dearth of >>>>> information on this out there... >>>>> >>>>> I'm modifying some of the preferences in our Nuke setup globally, >>>>> notably the autosave location, which is a custom location (not the same >>>>> as the default environment variables). I set those preferences by >>>>> changing the knobs and then using a hacky script I found on the forums >>>>> by Javier Garcia to save the preferences. If I don't do the save, then >>>>> if the user opens the prefs and hits cancel, the changes are lost. >>>>> >>>>> It seems like a backwards way to solve some of this. There should be >>>>> some kind of studio preference which simply overrides any user values. >>>>> Is everyone just using this same trick? >>>>> >>>>> Thanks! >>>>> Den >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nuke-python mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>> >>>>> >>>> -- >>>> ben dickson >>>> 2D TD | [email protected] >>>> rising sun pictures | www.rsp.com.au >>>> _______________________________________________ >>>> 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] >> <javascript:_e(%7B%7D,'cvml','[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
