[Bf-committers] RNA Extension Registration
Brecht Van Lommel
brechtvanlommel at pandora.be
Thu Feb 10 22:59:38 CET 2011
So, looking at this again, as I understand it, the main decision that
needs to be taken is if we want auto registration to be opt-in or
opt-out. The only difference would be a few standard lines at the end
of scripts. I prefer this to be opt-in personally.
Regarding the implementation, that's hard to judge for me, but I guess
that in the case we decide on opt-in and that means the implementation
can be simplified in places, then it's logical to do so.
On Thu, Jan 27, 2011 at 9:57 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> Hi Martin,
> Just looked into your patch and while its improved and more flexible
> improvement its still creating an environment which is overkill IMHO.
> This goes back to the problem that you want to keep auto-registration
> and I'm not convinced its better then an api which gives a convenience
> registration function for script authors to access.
> This can simply be solved by collecting classes and having a single
> function to register them, anything more then this increases
> complexity of our internals significantly and only means we avoid a
> few lines at the end of the scripts.
> Updated my patch posted earlier to the ML, with minor changes.
> - Uses metaclass to collect classes as we agreed.
> - Includes line of class definition to include on registration errors
> (like you added with yours).
> Attached the updated patch here.
> Re #, IDPropertyGroups can be defined like operators. Probably
> nobody did this because adding properties to existing types Scene,
> Group, Mesh etc.. cant be done this way.
> - Campbell
> On Thu, Jan 27, 2011 at 1:10 AM, Martin Poirier <theeth at yahoo.com> wrote:
>> After talking with Campbell at length this morning (my morning), here's what was agreed upon.
>> - Keep using a metaclass to build a list of extension type per module
>> - The automatic registration system should support both runtime and define time registration. 
>> - Turning on or off automatic registration should require *at most* a single function call at the end of a module. 
>> The only last decision to take, as far as I understood (and I hope there wasn't a misunderstanding) is whether or not the automatic method should be opt in or opt out.
>> I've made some changes to the automatic system today (patch attached) that would make it easy to support opt in or opt out painlessly. It also demonstrates how the metaclass can be used to gather more information about the types (file and line where they are defined).
>> Don't read the following unless you want boring details on stuff most people don't care about (and shouldn't)
>>  Currently, IDPropGroups are treated separately than other types. That was a work around for previous coding practices and needs to be removed.
>>  Define time is the usual case: built in modules and addons. Runtime is both for definitions during a call to a module and for text window execution (although the later one could probably work like built-in modules).
>>  Something like bpy.utils.manual_registration() to turn off or bpy.utils.register(__name__) to register all types in a module. This removes the need of doing shenanigans like calling the module's register method if __name__ == "main" to support text window execution and whatnot, which, IMHO is a good thing.
>>  I also suggested we support optional register and unregister class methods in RNA types. This would help remove code entropy and make the definitions more self contained (for example, a class defining OBJ import could also contain the code to add and remove itself from menus instead of having it in the module's function). The jury is still out on whether that's a good idea or not.
>>  We both agreed that IDPropGroups properties should be defined using the same syntax as operator properties (if possible) instead of having to add them post registration. Campbell said he'd try his hand at that later this week (IIRC).
>> Bf-committers mailing list
>> Bf-committers at blender.org
> - Campbell
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers