Hi Martin, Not capable of grasping your discussions with Campbell on this topic, I proposed to ask arbitration by a third person who knows this well. We're all equally stubborn fallible humans you know, and who's "right" or "wrong" then is less relevant than just moving forward. :)
If you think Brecht has all information you want him to know, let's go for his advice. -Ton- ------------------------------------------------------------------------ Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 17 Jan, 2011, at 14:20, Martin Poirier wrote: > > > --- On Mon, 1/17/11, Campbell Barton <ideasma...@gmail.com> wrote: > >> Agree panel order shouldn't be a >> factor in this discussion, it should >> be solved irrespective of registration so addons panels can >> be added in a logical order. > > Ideally, this should be done before going out of beta. > >> Though I'm still for auto-registration removal even if its >> bug free, >> most likely re-iterating from previous mails. > > It's not so much the reiteration of your same arguments that bugs me > but the fact that you've completely ignored the problems with the > registration order and properties registration that I've highlighted > many times and that has to be dealt with regardless of the > registration method if we want to correctly and cleanly handle > enabling and disabling addons (which you seem to think is an > argument for manual registration but is completely irrelevant). > >> - to me it feels mysterious that blender is operating on >> classes >> without being asked & errors don't trace back to >> authors code. > > The traceback issue can be fixed quite simply. The Metaclass has > more info than manual registration on the class definition itself > (you can have the file and line where the class is defined if that's > what you want). > > As for blender operating on classes without being asked, that's the > whole point of inheritance. > >> - in simple cases where all classes are registered its not >> a big win >> to have it automatic, in complicated cases of dynamic >> runtime registration this gets in the way. > > Yes, you did raise that point last time, it was bunk back then too. > > Can you show an example of dynamic runtime registration that deals > correctly with registration order and unregistration without making > a truckload of assumptions or not working at all? > > Registration order is tightly coupled with internal workings of > Blender, exposing that to python is completely ridiculous. > >> - it makes internals more complicated we need to support - >> 3 cases: >> direct execution, modules and addons. > > There's only two cases, runtime execution and delayed execution. > > Modules are addons that are registered automatically after definition. > >> - 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. > > Didn't I addressed Nathan's issues last time? > > There's nothing about autoregistration that prevents runtime > definition of classes. > >> It is regrettable that I accepted this patch in the first >> place, but I >> felt some obligation to do so since Martin addressed the >> issues that >> concerned me, also because Brecht and Andria also approved >> of this >> functionality at the time. > > It's regrettable that I tried to address the real problems two > months ago, after which you said you'd have to look into it yourself > and never came back until now, trying to force a decision again. > > It's regrettable that you think autoregistration is an opaque black > box just because there's the word metaclass in there. > > But most of all, it's regrettable that you think shoving that back > in the ands of python developers will solve all problems magically > when in fact it means having to write more documentation with > warnings all over the place about proper registration order. > > 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