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
