Hi, I'd also be interested in knowing what, specifically, Campbell thinks is overkill.
And you're right, opt in could be a bit simplified, depending on how far we want to go (have the runtime case be completely manual or not, I have ideas to handle both). Martin --- On Thu, 2/10/11, Brecht Van Lommel <brechtvanlom...@pandora.be> wrote: > From: Brecht Van Lommel <brechtvanlom...@pandora.be> > Subject: Re: [Bf-committers] RNA Extension Registration > To: "bf-blender developers" <bf-committers@blender.org> > Received: Thursday, February 10, 2011, 4:59 PM > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers