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 <the...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
