I would suggest a more intelligent Menu.py which dynamically creates the menus you need. An environment variable can be used to store what versions of plugins are requested and you could resolve paths/icons/etc. on the fly.
Assuming your package system is written in python you could provide helper methods to handle all of this and use them in Init.py too - connect to a database of plugin dependencies for gizmo's, embed the info in metadata and the same tools can be used for historical purposes. It's functional, not just a resource file - I'm not too sure if there are any specific limitations as to the context - haven't found any myself. Cheers -- Colin Doncaster Peregrine Labs www.peregrinelabs.com On 2011-05-09, at 4:50 PM, Shawn Neely wrote: > Hello- > > I'm embarking on a project to develop and install a growing number of Nuke > plug-ins, and wondering if anyone has any strong opinions about how best to > organize plug-in files, icons, menu hooks, etc. The issue applies both to a > "source" development tree and the final installed location(s) on NUKE_PATH, > which may be different. (For example, the source tree could branch off into > a separate section for menu icons, while the installation directory could be > flat and simply mix icons and .so files all together in a common directory.) > > One motivating principle is that I think it would be convenient to structure > each plugin as a self-contained "package". All the relevant files for a > particular plug-in would be located under a common node (a directory with the > name of the node). This would apply to both source and install trees. The > corollary, however, is that each plug-in would have its own menu.py file in a > subdirectory, and the construction of nuke.pluginPath() could result in the > concatenation of many subdirectories. Is there any significant performance > disadvantage here? From an organizational standpoint, having a separate > menu.py file for each plug-in makes it easier to merge and maintain new > development, eliminating the need to constantly edit a monolithic menu.py > file. But I recall that Shake had some serious start-up penalties when > opening and parsing a lot of small files, and would like to avoid those kinds > of potential issues with Nuke. > > One potential scenario, for example, might be to keep the source menu.py > files separate, but then automatically concatenate them all together into one > big menu.py file during a "make install" step, or something like that. > > Any advice, file/directory naming examples, or cautionary tales would be most > welcome, thanks! > > cheers, > Shawn Neely > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
