Support for keeping preferences of disabled add-ons #71486

Open
opened 2019-11-11 07:59:17 +01:00 by Campbell Barton · 17 comments

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 #71451 (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.

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 #71451 (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.*
Author
Owner

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

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

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

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos
Member

Added subscriber: @BrendonMurphy

Added subscriber: @BrendonMurphy

Added subscriber: @joules-2

Added subscriber: @joules-2

Added subscriber: @jfmatheu

Added subscriber: @jfmatheu

Any news on this?

**Any news on this?**

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @c2ba

Added subscriber: @c2ba

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.

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.

Added subscriber: @stjerneidioten

Added subscriber: @stjerneidioten

Added subscriber: @RobertN

Added subscriber: @RobertN

Added subscriber: @mkaito

Added subscriber: @mkaito

Added subscriber: @julienh

Added subscriber: @julienh

Added subscriber: @marcolomeo

Added subscriber: @marcolomeo

Added subscriber: @randum

Added subscriber: @randum
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:25:04 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
14 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#71486
No description provided.