Quicker Text Editing in Blender (Part 12): Preferences + Properties = Bugs

This references that, which references the other…

Context

When making videos in Blender’s VSE I use a lot of text sequences for captions and the like. Doing common operations — like changing colour, location, size etc — can be slow when using the GUI, so I am writing an addon called QTE (Quicker Text Editing, pronounced ‘cutie’) to make the process faster. This series of posts outlines the process and tries to explain parts of the Blender API that I interacted with along the way.

Show all parts (click to expand)

Parts:

1. Part 1: What We Want To Do & Proof of Concept
2. Part 2: Operators, Dynamic Classes & a Basic Script
3. Part 3: Keymaps
4. Part 4: User Preferences (& Panels)
5. Part 5: QTE Alpha Release
6. Part 6: Preferences and the right keymap
7. Part 7: QTE Beta Release (& ‘Remove Binding’ Operator)
8. Part 8: Bugs & Features
9. Part 9: Prototyping Appearing Text
10. Interlude: Why is my Blender addon panel property read only? (Solved)
11. Part 10: Beta 2 Release (+ Development Hurdles)
12. Part 11: Reflection and Next Steps
13. Part 12: Preferences + Properties = Bugs
14. Part 13: CollectionProperty, KeyMapItem ID, Preferences Pitfalls

Understanding What I Have Already Done

Before I do anything with saving or exporting settings to disk, I need to go back and understand what I did. Factors affecting this:

• ❌ I did this months ago
• ❌ My understanding at the time was somewhere between ??? and ‘not super clear‘
• ✅ I have a better understanding of properties and how they need to be shared between operators and panels

The text operators and preferences panels I defined to get beta1 out the door were done in a way that superficially worked�, but has odd quirks, which is my way of saying ‘it buggy as heck’ without saying it.

---

� There must be a term for those kinds of implementations. The ones where you’re working with an API that isn’t terribly clear, there are seemingly multiple overlapping and redundant ways of doing things with different side effects, so you make your best guess based on documentation and observed behaviour; and it works insofar as you can tell in limited testing, but any proper QA would show it falls apart. Fragile comes to mind, but I’m sure there’s a better term.

---

Preferences Don’t Save (Sometimes)

The presets and key bindings work fine in the session, but if you restart…

You may notice that the second colour preference (‘Red’) loses its name and colour. If I had changed the hotkey after setting those, it would have kept them. That’s also the reason for ‘Bart’ in there as a size preset- only changing the name from ‘Bar’ to ‘Bart’ caused the setting to revert; but changing the binding ‘saved’ the setting.

Digging Further – Preferences vs Keymaps

Why is it doing that? Let’s take a look at the actual preferences (in Blender console: C.preferences.addons['quicker-text-editing'].preferences):

It really should have size as an attribute! The class does:

class SizePresets(bpy.types.PropertyGroup):
    """A PropertyGroup to define the structure of user presets (sizes)"""
    name: bpy.props.StringProperty(
        name="Name",
        description="Size preset",
        default="One"
    )

    size: bpy.props.FloatProperty(
        name="Size",
        subtype='NONE',
        description="Size for text",
        min=-2000.0,
        max=2000.0,
        default=100.0  # font size
        )

    relative: bpy.props.BoolProperty(
        name="Relative",
        description="Is size change relative?",
        default=False,
    )

What preferences are there?

So they are both incomplete and empty.

Let’s look at the keymaps:

Aha! That’s where all the presets and options are.

Why is this happening?

The long and short of it is that I implemented the preferences for the addon (QTEPreferences class) to store all the options relating to the text operators with their keymap item. This made sense at the time, and it possibly still does from a settings persistence perspective- as long as we can extract that info, save it, and recreate it it doesn’t particularly matter where it is stored.

Disabling and Re-enabling Addon Loses Everything

This is related to the implementation, so the previous sections are relevant. If a picture is worth a thousand words, a video must be worth around a million:

My understanding (read: ‘guess’) is that the keys persist as they are part of the user keymap, but when the plugin is unloaded the operators and property classes are de-registered, which leaves the bindings without needed data.

Relaunching blender does cause the UI to sort itself out:

But the bindings are replaced with defaults.

It should be possible to avoid this by removing keymap entries as part of addon unregister() process.

Next Steps

1. I would like to know the reason why the operator properties are not updated until the keybinding updates, but that’s mostly out of curiosity. I think I can work around it by doing what I did for the ‘appearing text’ options- pull the properties into a structure that is referenced by the keymap and the preferences panel.
2. I also need to unregister the key bindings when the addon is unregistered.
3. If I am moving operator preferences for text actions into the addon preferences data structure, I should also move the ‘appearing text’ options from where they are stored (bpy.context.window_manager) presently into the preferences as well

Once these have been taken care of I can move on to persistence of settings.