Hi Deke, The main reason I see a use for this in connection with a project is to be able to save the state of as much as possible for a specific project's production. Some studios have pipelines that vary depending on the project, however preferences are continuously evolving and can change quite a bit. If an old project needs to be restored it could be useful to utilize the state of everything, preferences included. To me it makes sense to save the state of as many task-related variables as possible in a project.
Off the top of my head, a really simple example would be just to see the most recently opened files, or to be able to reuse old bookmarks in the file chooser. Or even a tweaked desktop layout to deal with tasks specifically related to a job. As well, It might sound odd at first, but being able to "experience" an old environment is really helpful to jog the memory if I need to work on something I haven't seen in a while. Jon On Tue, Oct 20, 2015 at 3:08 PM, Deke Kincaid <[email protected]> wrote: > I'm just curious, what would preferences have anything to do with loading > the Nuke project? It just seems very unrelated. File level "preferences" > related to a project are under root which is saved in the nuke file. If I > was an artist inheriting someone else project I would go batty if I had to > use another artists custom prefs. Also with evolving pipelines old prefs > could actually break the ability to open a file in some cases. > > On Tue, Oct 20, 2015 at 10:28 AM, jon parker <[email protected]> wrote: >> >> I actually prefer user settings to be per-project. It's cleaner when >> jumping between projects, and when an old project needs to be >> resurrected one can know that everything will reload the same way: >> layout, personal keyboard preferences, etc. >> >> Houdini lets you set a variable called "HOUDINI_USER_PREF_DIR" that >> will force Houdini to look there first instead of $HOME. My memory of >> Maya is fuzzy but I believe it also lets you change that. >> >> Jon >> >> On Mon, Oct 19, 2015 at 7:12 PM, Frank Rueter|OHUfx <[email protected]> >> wrote: >> > Why would you want to do that though? What kinda of setup are you after? >> > >> > >> > >> > On 10/20/2015 09:37 AM, jon parker wrote: >> >> >> >> Right, thanks, I missed that... >> >> >> >> So it looks like the only way to change the user's pref location is to >> >> override the $HOME variable during startup? >> >> >> >> Jon >> >> >> >> On Sat, Oct 17, 2015 at 3:37 PM, Deke Kincaid <[email protected]> >> >> wrote: >> >>> >> >>> It doesn't override HOME, it just adds the path to your nuke path. >> >>> .nuke >> >>> is >> >>> always executed last. This is in the doc links I posted. >> >>> >> >>> -deke >> >>> >> >>> >> >>> On Saturday, October 17, 2015, jon parker <[email protected]> >> >>> wrote: >> >>>> >> >>>> I see, >> >>>> I wasn't aware that NUKE_PATH would override the default preferences >> >>>> location in HOME. >> >>>> >> >>>> Simple solution, then, thanks. >> >>>> >> >>>> Jon >> >>>> >> >>>> On Fri, Oct 16, 2015 at 9:53 PM, Frank Rueter|OHUfx <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>> You could use the nuke.pluginAddPath() command in the master init.py >> >>>>> in >> >>>>> your >> >>>>> NUKE_PATH and use the USER env variable to construct a path relative >> >>>>> to >> >>>>> each >> >>>>> user. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 10/17/2015 02:40 PM, jon parker wrote: >> >>>>>> >> >>>>>> Greetings Nuke-users, >> >>>>>> I want to be able to create a .nuke folder on a per-project basis >> >>>>>> for >> >>>>>> users. So each user, for each job, has its own batch of settings, >> >>>>>> plugins, fancy layouts... and so on and so forth. >> >>>>>> >> >>>>>> Are there any environment variables to send to Nuke to change the >> >>>>>> default user settings dir? Or should I just wrap the nuke command >> >>>>>> in >> >>>>>> a script and change $HOME there, before launching nuke? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Jon >> >>>>>> _______________________________________________ >> >>>>>> Nuke-users mailing list >> >>>>>> [email protected], >> >>>>>> http://forums.thefoundry.co.uk/ >> >>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Nuke-users mailing list >> >>>>> [email protected], http://forums.thefoundry.co.uk/ >> >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >>>> >> >>>> _______________________________________________ >> >>>> Nuke-users mailing list >> >>>> [email protected], http://forums.thefoundry.co.uk/ >> >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >>> >> >>> >> >>> _______________________________________________ >> >>> Nuke-users mailing list >> >>> [email protected], http://forums.thefoundry.co.uk/ >> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> >> _______________________________________________ >> >> Nuke-users mailing list >> >> [email protected], http://forums.thefoundry.co.uk/ >> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > >> > >> > _______________________________________________ >> > Nuke-users mailing list >> > [email protected], http://forums.thefoundry.co.uk/ >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users _______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
