[Bf-committers] RNA Extension Registration

[Martin Poirier]

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 <brechtvanlommel at pandora.be> wrote:

> From: Brecht Van Lommel <brechtvanlommel at pandora.be>
> Subject: Re: [Bf-committers] RNA Extension Registration
> To: "bf-blender developers" <bf-committers at 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 <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.
> > 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
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>