To prevent collisions 2.8x enforces naming conventions…This constraint applies to the bl_idname of each class (or the class name which uses it if no bl_idname is defined in the class)…
And specifically states that, for operators (which use the _OT_ naming scheme), this is a valid name:
Because the wiki states that “This constraint applies to the bl_idname of each class (or the class name which uses it if no bl_idname is defined in the class),” why does this bl_idname:
Give an error:
RuntimeError: Error: Registering operator class: 'ChangeTypeBaseClass', invalid bl_idname 'MAPLUS_OT_changetypebaseclass', at position 0
I just want to FULLY understand the exact requirements for 2.80, because it seems that they are either unclear or incorrect as written (and this is blocking the release of my addon, I don’t want to release a version that does not work with an official 2.80 release or RC if the logic described on the wiki is in some way not finished, which seems to be the case).
Goal of this post is to fully settle these questions and arrive at a final answer.
Thanks // 2.80 is fantastic, hoping to release a fully compliant, updated version of my addon for it.
The 2.8x and 2.7x rules conflict, as far as I can tell (I cannot find a good, exhaustive list of 2.7 rules, do we have one?). The only rules I have any knowledge of are that bl_idname must contain a dot and be lowercase. Problems/questions are listed inline:
ISSUE 1: (Conflicts/source link provided)
A bl_idname must be a string containing only lowercase letters, digits and underscores, plus exactly one dot; hello.hello satisfies these criteria. Apart from that there are apparently no restrictions in the bl_idname.
I have PropertyGroup (bpy) subclasses in my addon, but these seem to have no requirements in the wiki. I also have other non-bpy classes. It is confusing to see two different naming conventions, where some classes have a cryptic sequence of uppercase characters and others do not with no obvious reason why (in an addon especially). Is there any guidance for other bpy subclasses, to create coherent/consistent code?