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.fo...@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@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