[Bf-committers] Removing auto registration

Campbell Barton ideasman42 at gmail.com
Wed Jan 26 09:35:17 CET 2011


Uploaded a patch to the tracker which removes automatic registering
but adds a convenience function:
http://projects.blender.org/tracker/index.php?func=detail&aid=25809&group_id=9&atid=127

The class list we had before can be avoided by using this api call.

def register():
    bpy.utils.register_module(__name__)

def unregister():
    bpy.utils.unregister_module(__name__)

... where __name__ is the python builtin for the module name.

If the order is important a more verbose class list can be used as
before auto-register was added.

This doesn't prevent a more advanced registration function to be
written which handles dependencies as Martin suggests, it just means
the script author can choose to manually manage registering.

- Campbell

On Tue, Jan 25, 2011 at 10:24 AM, Tom Edwards <contact at steamreview.org> wrote:
> I have several operators in my script and was always annoyed at their
> lacklustre ordering in search results. Turns out that re-arranging them
> within the script fixes that problem too. +1 for manual registration!
>
> On 24/01/2011 2:56, Campbell Barton wrote:
>> Martin correctly reprimanded me for being vague on the kinds of
>> problems that auto-registration causes, so I had a look into it today
>> :)
>>
>> Started by looking into a registration bug in the tracker by removing
>> auto-registration locally to check if this was causing the problem.
>>
>> https://projects.blender.org/tracker/index.php?func=detail&aid=24132&group_id=9&atid=498
>> https://projects.blender.org/tracker/?func=detail&aid=24498&group_id=9&atid=498
>> (the same bug but wasn't obvious initially)
>>
>> In short, it is.
>> Any subclass of an IDPropertyGroup is instantly registered and never
>> unregistered, but this was a known problem.
>>
>> If we remove auto registration editing existing addons to correctly
>> load/unload is not a big problem, I did one script as a test.
>> Though Martins answer is to fix the auto-registration which is all
>> very well, except that I still would rather remove it.
>>
>> The other things are things are less immediately useful. For example
>> registering operators automatically, and removing them at runtime
>> while the script stays running.
>> How would this be done with the current system?, from what I can tell
>> it cant be.
>>
>> @Marin, I think you misrepresent my position in one respect, You say
>> that I would have users solve registration problems themselves. This
>> isn't true, we can have a function which does a smart register of all
>> classes defined. I'm just against this being built into the class.
>>
>> Infact when removing auto registration I added a utility to register
>> all classes in a module because defining class lists is tedious (as we
>> had before auto-registration was introduced).
>>
>> def register():
>>      bpy.utils.auto_register(globals())
>>
>> This registers all classes defined in that module, scanning globals is
>> ugly but I think we can get a good brief function and avoid class
>> lists.
>>
>> So I don't think this should be seen as a choice between
>> automatic+clear OR bloilerplate+verbose.
>> For scripts which register every class like UI scripts we can have a
>> single function, nicer then having to define a class list.
>> Such a function could of course be extended to do dependency calculation too.
>>
>> Btw, you mention finding the class line in python for errors, python
>> cant know where a class is defined, its just not stored. pythons
>> 'inspect' module just a regex search on the source to find the most
>> likely match, not useful for blender internal texts.
>>
>>
>> - Campbell
>>
>> On Sat, Jan 22, 2011 at 10:56 PM, Sergey Kurdakov
>> <sergey.forum at gmail.com>  wrote:
>>> Hi,
>>>
>>> I'm sorry, as actually I would need to dig into details to understand all
>>> the subtleties,
>>> but few sparse thoughts
>>>
>>> order:
>>> is it possible to have a two step registration? such that first - there  map
>>> is created ( or graph
>>> http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/index.html )  like it is
>>> done in boost.python (starting files  to look at
>>> are \boost\python\converter\registry.hpp
>>> | boost\python\converter\registrations.hpp  )  of types ,
>>> where all requested types are registered upon class creation and then
>>> then the whole system is glued together ( registered ) looking for
>>> unavailable parts and the next step?
>>>
>>> will it solve
>>>> Matt Ebb and Nathan Vegdahl have complained about auto-registration
>>>> in its current state fir renderman support which does dynamic
>>>> generated classes from shaders, and rigify for rig types.
>>> if yes. then why two step registration is not an option ( or will it add too
>>> much complexity)?
>>>
>>> Regards
>>> Sergey
>>> _______________________________________________
>>> 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
>


More information about the Bf-committers mailing list