Hi Campbell, What might be helpful is to have an example of recommended practice. Speaking for myself: right now it's often a matter of experimentation to get things to work and this might result in solutions that depend on bad practice.
For example, if you wish your add-on to display a panel with a custom value depending on what scene you are in, it would seem logical to add a custom property to the Scene ID class. Initialising this property from within the panel draw code is bad practice, but what to do? Initialising upon registration fails when the add-on is enabled and saved to the default .blend (context doesn't exist yet when add-on is run at startup). And not initialising of course results in an error when the panel (displaying the custom property) is drawn. > This raises the question: are most extension authors reading bf-committees > mailing list?, should we discuss python api design on bf-python? > Bf-python is probably the most logical place to discuss python api design, but you raise a good point: how many script writers are actually subscribed to it? For the record, I'm reading both bf-committers and bf-python. Yours friendly, Bart _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
