Hi, 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. Brecht. On Thu, Jan 27, 2011 at 9:57 AM, Campbell Barton <ideasma...@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. > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
