In the newest releases (somewhere around 2.65) there was a big change which prevents addons from accessing context or blend data at registration. After reading through the [BF-Python] emails, I’m of the opinion the changes are for the better despite my feelings getting hurt by really broken add-ons. Let’s discuss some good and bad practices, work arounds and scenarios…in the hopes of improving our brains, and improving our add-ons.
I’ll start by positing a few scenarios which I can imagine some python add-on dev’s saying out loud…
I have an add-on which different people will use slightly differently. I would like them to be able to store some settings locally on their machine so each time they start blender, these settings are the same and my add-on behaves to their liking. When, where, and how, do I start, continue and stop those settings?
Example: the size in pixels of a pie menu radius will be different based on peoples eye-sight, screen resolution and screen size.
I have some arbitrary variable which is going to change while the user interacts with my add-on and their blend data. It only needs to be around while blender and my add-on are running so I can keep track of something. Eg, I’d like to keep up with something throughout a workflow. When blender closes, I’m no longer interested in it. If a user sends their file to someone else with my addon, that variable does not need to come along. When, where, and how, do I start, continue and stop using that variable?
Example: I wan’t to keep track of how many times a particular operator has been used since my add-on initialized.
My add-on has some resources it uses, and they need to be in bpy.data for me to really use them. I wan’t them locked and loaded ready to go after my addon starts. If I wait until the user calls a function to load it, it’s going to really slow down that first user interaction. However, I dont need them saved to any .blend files because they are only used by my addon. When, where, and how, do I start, continue and stop loading those resources? We don’t want them in bpy.data because if a new blend file is opened…our resources will go away.
Example. An image is used to draw with bgl. The image needs to be in bpy.data.images so the built-in gl_load() function can be used.
I’ve seen all these tackled by stashing properties in bpy.context.scene when add-ons registers. Or loading/linking/appending resources out of blend files in the add-on directory(Mackrakens material library). Now those things are out of the question at add-on registration.
Time to show and tell how you all have tackled these problems or others related to the new API, cleanly or not. Some best practice advice would be great too.