Add-ons Blender 2.79 - more generic Panel rename code #50726

New Issue

This is a task is part of #50357, but marking it as separate to not clutter the main one.

It introduces, like the title said, a more generic function for add-ons that don't have the feature and modify the existing scripts if needed, as some more robustness in case of a failure.

What needs to be changed for individual add-ons:

The panels list should contain the panel classes that need to be altered.
The message variable in update panel needs to be set to the name of the Add-on.
The error message already gives the script name.

Example for Bool Tool:

# 1) Define Panel classes for updating
panels = [
        BoolTool_Tools,
        BoolTool_Config,
        BoolTool_BViwer,
        ]


def update_panel(self, context):
    # 2) update this message
    message = "Bool Tool: Updating Panel locations has failed"
    try:
        for panel in panels:
            if "bl_rna" in panel.__dict__:
                bpy.utils.unregister_class(panel)

        for panel in panels:
            panel.bl_category = context.user_preferences.addons[__name__].preferences.category
            bpy.utils.register_class(panel)

    except Exception as e:
        print("\n[{}]\n{}\n\nError:\n{}".format(__name__, message, e))
        pass

Example of the error message on double register:

[object_boolean_tools]
BoolTool: Updating Panel locations has failed

Error:
register_class(...): already registered as a subclass

As a part of this task, add-ons can have their locations for panels altered conforming with the current policy of not creating new tabs when not needed.

This is a task is part of #50357, but marking it as separate to not clutter the main one. It introduces, like the title said, a more generic function for add-ons that don't have the feature and modify the existing scripts if needed, as some more robustness in case of a failure. What needs to be changed for individual add-ons: 1) The panels list should contain the panel classes that need to be altered. 2) The message variable in update panel needs to be set to the name of the Add-on. The error message already gives the script name. Example for Bool Tool: ``` # 1) Define Panel classes for updating panels = [ BoolTool_Tools, BoolTool_Config, BoolTool_BViwer, ] def update_panel(self, context): # 2) update this message message = "Bool Tool: Updating Panel locations has failed" try: for panel in panels: if "bl_rna" in panel.__dict__: bpy.utils.unregister_class(panel) for panel in panels: panel.bl_category = context.user_preferences.addons[__name__].preferences.category bpy.utils.register_class(panel) except Exception as e: print("\n[{}]\n{}\n\nError:\n{}".format(__name__, message, e)) pass ``` Example of the error message on double register: ``` [object_boolean_tools] BoolTool: Updating Panel locations has failed Error: register_class(...): already registered as a subclass ``` As a part of this task, add-ons can have their locations for panels altered conforming with the current policy of not creating new tabs when not needed.

Changed status to: 'Open'

Added subscriber: @VukGardasevic

Added subscriber: @BrendonMurphy

hi, it could be too much to implement this now, might be a better 2.8 target? we still have not updated the contrib addons to the first panel location as option changes, if we want to do this, it needs to be all or none.
I do agree with the change. i think also we could look at adding the base code into addons_utils.py so it's accessible by all addons & not on a per addon base.

hi, it could be too much to implement this now, might be a better 2.8 target? we still have not updated the contrib addons to the first panel location as option changes, if we want to do this, it needs to be all or none. I do agree with the change. i think also we could look at adding the base code into addons_utils.py so it's accessible by all addons & not on a per addon base.

As for the implementation it shouldn't be a problem apart from a series of commits, as it doesn't change the functionality, however I'm open to a decision in regards to it.

As for 2.8 depending on how the add-ons are handled (like being registered per workspace or similar) probably there will be some API or utils code that handles the location of the Panels in the UI or specific tab locations.

If during 2.79 development we make some more generic code in addon_utils I'm fine with that too. :)

As for the implementation it shouldn't be a problem apart from a series of commits, as it doesn't change the functionality, however I'm open to a decision in regards to it. As for 2.8 depending on how the add-ons are handled (like being registered per workspace or similar) probably there will be some API or utils code that handles the location of the Panels in the UI or specific tab locations. If during 2.79 development we make some more generic code in addon_utils I'm fine with that too. :)

@VukGardasevic I think it's fine to go ahead with this soon, It's a good change & fits code design well.
One question, why the use of:

if "bl_rna" in panel.__dict__:

you could use:

cls.is_registered

or is it needed at all? thanks.

@VukGardasevic I think it's fine to go ahead with this soon, It's a good change & fits code design well. One question, why the use of: ``` if "bl_rna" in panel.__dict__: ``` you could use: ``` cls.is_registered ``` or is it needed at all? thanks.

Raising to confirmed as this is a developer task

move to high task as this task belongs to dev tasks

Changed status from 'Open' to: 'Resolved'

Since we are in the RC1 I think this task can be closed.

Probably there could some more add-ons added having this feature (like Tissue or ANT and some exporters in the contrib that have panels in the TOOL_PROPS section) but that is something that is not a priority as the first two have rational locations / layouts, and the contrib ones are not part of the release.

Since we are in the RC1 I think this task can be closed. Probably there could some more add-ons added having this feature (like Tissue or ANT and some exporters in the contrib that have panels in the `TOOL_PROPS` section) but that is something that is not a priority as the first two have rational locations / layouts, and the contrib ones are not part of the release.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add-ons Blender 2.79 - more generic Panel rename code #50726