Maniphest T98503

addon preferences changed by code (not by user in UI) are not saved
Needs Information from Developers, Normal
Actions

Assigned To
None
Authored By
Julien DUROURE (julien)
May 30 2022, 5:39 PM
Tags
  • BF Blender
  • User Interface
  • Python API
Subscribers
Germano Cavalcante (mano-wii)
Julien DUROURE (julien)

Description

System Information
Operating system: Ubuntu
Graphics card: RTX

Blender Version
Broken: master
Worked: ?

Short description of error
addon preferences changed by code (not by user in UI) are not saved at Blender close.

Exact steps for others to reproduce the error

  • Open Blender. Load Factory Settings, close Blender.
  • Open Blender
  • In console, change an addon preferences. For example, change device of Cycles : bpy.context.preferences.addons['cycles'].preferences['compute_device_type'] = 1 (this change to CUDA)
  • Close Blender. No log saying preferences are saved.
  • Open Blender again, check that device is still None. pref save is KO
  • Change preferences to "CUDA" by clicking with your mouse
  • Close Blender
  • See that a log saying preferences are saved
  • Open again, you can see that preferences are set to CUDA, pref save was OK

Related Objects

Event Timeline

Julien DUROURE (julien) created this task.May 30 2022, 5:39 PM
Germano Cavalcante (mano-wii) added a subscriber: Germano Cavalcante (mano-wii).May 31 2022, 5:11 AM

Maybe related to T71593: Changes to a PropertyGroup in the preferences of an addon do not trigger the flag indicating changes to save.

Julien DUROURE (julien) added a comment.May 31 2022, 7:02 AM

Hello,
I first detected it in my own addon, where I used a BoolProperty, and my example here is an EnumProperty.
So it seems not linked only with PropertyGroup

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Needs Information from Developers.May 31 2022, 3:29 PM

Analyzing the code, the tag to save changes in preferences is done by the button, not by the property.
Therefore, the context is different from what is reported here (See rB source/blender/editors/interface/interface_handlers.c:688-694)

But I agree that it seems wrong that the preferences not be marked as dirty when the value of a property is different from the one saved.

However, this just seems like a confusing definition of when the preferences are "dirty".
The preferences are "dirty", not when a property is different, but when the interface says that the new values need to be saved because a button was pressed in the preferences UI.

So if the property values are different from the saved one and the preference is not "dirty" it's not necessarily a bug imho.

We could change this behavior and move the update of the "is_dirty" flag to the properties. But would not that be confusing for the user saving changes to preferences out of an obvious context?

And if this is changed, how to keep the current behavior of addons that expose their properties in panels outside of the user preferences?

I'm not sure if making this change is worth it. I'll leave it to the User Interface team to evaluate what to do here.

NOTE: you can mark the preferences as dirty with: bpy.context.preferences.is_dirty = True
Pratik Borhade (PratikPB2123) added projects: User Interface, Python API.May 31 2022, 8:20 PM