[Bf-committers] Storing “global” (per .blend file) addon properties

dima glib dima.glib at gmail.com
Mon Feb 18 22:35:29 CET 2019


Currently, there is no good place to store “global” (per .blend file)
addon properties, but having it would be really useful for data which
isn't specific to any existing ID datablock.

WindowManager properties aren’t saved with the file (which is actually
useful in some cases).
So, right now, the only way to have something resembling "per-file"
properties is to store them in a Scene (if they should be subject to
Undo) or in a Screen (if they shouldn’t be affected by Undo). This is
quite bad, since the user can unintentionally reset the addon’s
properties just by deleting/creating/renaming scenes or screens.

There are two possible ways to solve this, in my opinion:

A) Add a couple of extra fields to BlendData, which the addons would
be able to extend with arbitrary bpy props. For example,
bpy.data.addon_props (undoable) and bpy.data.addon_props_ui (not
undoable).

B) Add a mechanism similar to addon preferences. I.e., an addon could
register a subclass of, say, bpy.types.AddonGlobalProps, and later
access it via bpy.data.addons[__name__].global_props.

What are your thoughts?

Currently I'm lacking the necessary knowledge/time to create such a
patch myself, but at least I hope this makes people more aware of the
issue :-)

========
Some use-case scenarios:

1) An addon introduces its own "ID datablocks" (coordinate systems in
my case), which, like Blender's own ID datablocks, should be stored
independently from any other datablocks. Ideally, I would use
"undoable" per-file storage for that.

2) An addon which batch-exports objects in a scene. Export settings
for each format are supposed to be individual to each .blend file, but
shared among all scenes/screens/windows. Ideally, I would use
"not-undoable" per-file storage for that.


More information about the Bf-committers mailing list