Page MenuHome

Support for keeping preferences of disabled add-ons
Confirmed, NormalPublicDESIGN

Assigned To
None
Authored By
Tokens
"Like" token, awarded by Mir-Mir-Roy."Love" token, awarded by c2ba."Love" token, awarded by elfchief."Love" token, awarded by juang3d."Like" token, awarded by joules."Like" token, awarded by meta-androcto."Like" token, awarded by threedslider."Like" token, awarded by rjg."Like" token, awarded by gaiaclary."Like" token, awarded by JacquesLucke."Like" token, awarded by duarteframos."Like" token, awarded by jbakker.

Description

Currently disabling an add-on removes it's preferences.

Users may have many options for an add-on which they don't want to loose when it's disabled.

See T71451: Support for keeping preferences of disabled add-ons for a report on this issue.

Proposed solution:

  • When disabling an add-on which has preferences, keep the preferences instead of freeing them.

    Internally this could be a list of disabled add-ons, used to restore the preferences when enabling them later.
  • Add button to add-ons with preferences to reset preferences.

    While not essential, without this there is no way to reset an add-ons preferences, where there was beforehand.
  • Add a drop-down menu (replacing the current refresh button) which has a menu item to remove all unused add-ons (to prevent accumulation). This menu will contain the "Refresh" button too.

    Exact details for the UI can be changed, suggest to replace the "Refresh" button to avoid too much clutter for actions that aren't used often.

Event Timeline

Seems sensible to do this. Not qualms as far as I am concerned.

JPG (joules) added a subscriber: JPG (joules).
Campbell Barton (campbellbarton) added a project: Restricted Project.

I think this task might be important for a production context.

In production we have a launcher that is able to start Blender, add some additional addon paths (using tricks with addon_utils.paths()), and enable some addons we want in production.

Initially I wanted to avoid as much as possible changing preferences of the user from a production script. This is because the user might want to run Blender in a non-production context later, so we don't want to pollute its preferences with production related stuff.

So my idea was to enable addons with addon_utils.enable, or with the --addons option of Blender. This result in an addon which is active in Blender, but not enabled in preferences (unchecked).

Unfortunately, when the addon is not enabled in preferences, then its preferences do not even exist (access to bpy.context.preferences.addons[package] gives a" KeyError: 'bpy_prop_collection[key]: key "addon_package" not found'"). So I had to change my mind and use bpy.ops.preferences.addon_enable(module=addon_module) instead, which result in modifying user preferences :/
Now if I want to avoid this change, I can try to find some trick to disable the addon at the end of the session. But in that case the user will loose its preferences for this specific addon, which lead us to what is discussed here: a user should be able to retrieve its preferences for an addon even if it was disabled at some point.

So to summarize:

  • addon_utils.enable should create the entry bpy.context.preferences.addons[__package__] for the addon if it does not exist
  • if the addon was enabled in the past but is not now, bpy.context.preferences.addons[__package__].preferences should contain the old preferences
  • on the UI part, the preference panel should display some indicator that an addon has been enabled for the session (register() has been called on it), even if not enabled in preferences

Finally, all this discussion about production dependent stuff raise the following question: maybe a preference override system could be useful. I have no clear ideas about that, but it may happen that a user want to override a specific subset of its base preferences when he launched Blender from a production launcher. The launcher might also want to provide different default values for the preferences of an addon, than the one specified by the addon itself. For an example of such system, I think VSCode extensions preferences are quite good to take inspiration: there is default preferences, system preferences, user preferences and project preferences.