[Bf-committers] RNA Extension Registration

Campbell Barton ideasman42 at gmail.com
Thu Jan 27 09:57:05 CET 2011


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.
http://projects.blender.org/tracker/index.php?func=detail&aid=25809&group_id=9&atid=127

Re #[4], 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:
> Hi,
>
> 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. [1]
> - Turning on or off automatic registration should require *at most* a single function call at the end of a module. [2]
>
> 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).
>
> Regards,
> Martin
>
>
> Don't read the following unless you want boring details on stuff most people don't care about (and shouldn't)
> ===============================================================
>
> [0] Currently, IDPropGroups are treated separately than other types. That was a work around for previous coding practices and needs to be removed.
>
> [1] 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).
>
> [2] 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.
>
> [3] 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.
>
> [4] 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
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>



-- 
- Campbell


More information about the Bf-committers mailing list