[Bf-committers] RNA Extension Registration

Fri Feb 11 06:07:49 CET 2011

Hi Martin,
To me having registration logic in base classes is overkill in the
sense it adds higher level functionality (potentially dependency
checks & making decisions about how registration is done correctly).
  We agree that this functionality is useful so IMHO this is best made
into a separate function.

When I first proposed to go back to manual/opt-in registration it was
reasonable you asked I hold off and look into the issue in more detail
and better understand the problems I complained of,
but now this topic has got a lot of attention, we both understand it
enough to make a decision.

Since we outright disagree and have done for some weeks with no progress,
I don't think any more discussion is useful and we can fall back to
module owners.

Looking at who maintains this area, Brecht wrote the initial RNA class
registration, I have since made many changes, wrote bpy_types.py to
allow python classes to extend built in types.
You and Elia Sart have made valuable contributions (OperatorMacros &
RNAFunctions), but Brecht and myself have been primary authors &
maintainers of RNA & Python integration.

I asked Brecht to review both of our patches, and from his last mail
he also prefers opt-in auto-registration.

At this point I think you have to accept that we have made a decision
on the topic.

The concerns you raised about manual registration are valid.
We still don't have a dependency checking registration function (as
previously discussed) which would be would be useful so script authors
don't need to worry about class registration order.
We can continue improving this area without auto-registration, the
change is not limiting progress.

- Campbell

On Thu, Feb 10, 2011 at 11:10 PM, Martin Poirier <theeth at yahoo.com> wrote:
> 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
>>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
- Campbell