>From my personal experience I did not had any problem when we changed for autoregistration of panels, but I have issue when desabling and reenabling the addon due to custom properties. This is not related to autoregitration as it this happaned even before this change.
Xavier 2010/10/28 Martin Poirier <the...@yahoo.com>: > Hi Nathan, > > --- On Thu, 10/28/10, Nathan Vegdahl <ces...@cessen.com> wrote: > >> I think this may be one of those things that is convenient >> in simple >> cases, but is just troublesome in complex cases. For >> example, I'm >> still struggling to figure out how to make the Rigify addon >> unregister >> cleanly. Ditto with the porting project I did. >> It doesn't seem >> possible. But it was trivial with manual >> registration. > > It should be even more trivial with automatic registration. The only thing > you need to take care of is registered properties, and I'm not even sure if > those can be deleted correctly at this point (Campbell could confirm this). > > Registered properties is still the biggest pitfall, IMHO, and needs to be > addressed. (that doesn't have much to do with automatic registration of RNA > types though) > >> I would much rather manage the registration and >> un-registration >> manually, so I can guarantee that everything works cleanly >> even in weird corner-cases. > > Can you give an example of such a corner case? > > Or better yet, when you encounter a problem, please mention it on this list > (or to me directly, if you don't want to do it on a public channel) and it > will be looked it. The code is certainly not perfect and there's a couple of > things to keep in mind when coding that was much free for all before (I see > that as a good thing). > >> And it makes it difficult (impossible?), for example, to >> write a class >> (say, a panel) that is just meant to be inherited from, but >> not >> directly registered. > > There's some examples of that in the UI scripts (properties_material.py look > for the MaterialButtonsPanel class and its subclasses). The rule is that only > valid well defined classes should derive from RNA types, so if you have > common behaviors to define, use mixin classes. > > I actually think it's cleaner this way. When reading code, it's easier to see > which classes define behaviors and which are actual RNA types. > >> Anyway, just my 2 cents. I'm finding >> auto-registration to be a >> needless headache, for only minor convenience gains in >> simple cases. > > I'm finding the same thing, except in reverse. > > It removes a lot of needless boiler plate code, it ensures that every script > is a "good citizen" and correctly registers and unregisters RNA types when > the system needs and not when bad code mistakingly does it, it transparently > enables optional add-ons as well as interactive execution in a text buffer, > it gives a single point of entry for registration calls as well as the > possibility of easier debugging in those cases where registration fails and > gives a easy way internally to figure out what is defined where. > > Martin > > > _______________________________________________ > 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
