[Bf-committers] Removing auto registration

Tom Edwards contact at steamreview.org
Tue Jan 25 11:24:01 CET 2011


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
>>
>
>


More information about the Bf-committers mailing list