Hi, I don't really see the order problem as a problem we have to solve. If you're registering multiple things, then it seems logical to me that if A references B, you register B first and then A. It's not clear to me where these potential complex rules would show up?
Brecht. On Sat, Jan 22, 2011 at 5:33 PM, Martin Poirier <the...@yahoo.com> wrote: > Hi, > > The problem I have with taking a decision now is that we haven't solved the > order problem. > > If it turns out to require very complex rules, it might be easier to solve > automatically than manually (or vice versa). > > What I mean is that I don't think we have all the data to take a good > decision at this point. Especially if correctly solving the problem means > changes in the RNA api layer (it might), it would be better to start early > (before the API is stabilized too much). > > Martin > > --- On Sat, 1/22/11, Ton Roosendaal <t...@blender.org> wrote: > >> From: Ton Roosendaal <t...@blender.org> >> Subject: Re: [Bf-committers] Removing auto registration >> To: "bf-blender developers" <bf-committers@blender.org> >> Received: Saturday, January 22, 2011, 11:24 AM >> Hi, >> >> Yes that sounds clean and clear. But apparently there's >> more ways to >> solve the problem, and either way has pros and cons. When >> visions on >> such problems don't align, then how to decide? The >> maintainers and >> main contributors to the code then can have a final word. >> >> -Ton- >> >> ------------------------------------------------------------------------ >> Ton Roosendaal Blender Foundation t...@blender.org >> www.blender.org >> Blender Institute Entrepotdok 57A >> 1018AD Amsterdam The Netherlands >> >> On 22 Jan, 2011, at 16:24, Martin Poirier wrote: >> >> > Hi Ton, >> > >> > I'll try to explain this as simply as possible. >> > >> > Registering python classes with the RNA system has to >> be done in a >> > specific order to solve dependency issues. >> > >> > Unregistering (when unloading) also has to be done in >> a specific >> > order (not the same, maybe not just reverse order). >> > >> > There are situations for which a good order isn't >> currently known >> > (theorically, on paper). >> > >> > This is the registration order problem. >> > >> > >> > If we choose to go with manual registration, we have >> to solve that >> > problem and have very special guidelines for python >> programmers, >> > otherwise stuff will break. >> > >> > If we choose to go with automatic registration, we >> have to solve >> > that problem and then write code that applies that >> solution (if that >> > can't be done, at last resort, there could be a way to >> turn it off >> > in specific cases and have to do it manually). >> > >> > In either case, not solving the registration problem >> is a bad thing >> > and things will break. >> > >> > In my wiki pages, I've proposed a solution to the >> problem that seems >> > simple and can easily be applied to both automatic or >> manual >> > registration (it's a simple set of rules like: UI >> first, then >> > operators, then ...), all that's needed is for other >> people to >> > validate this. >> > >> > Again, regardless of what registration method we use, >> the order >> > problem has to be fixed (before we switched to >> automatic >> > registration, people use to shuffle stuff around until >> it appeared >> > to work, that's not a solution). >> > >> > Is that clear? >> > >> > Martin >> > >> > --- On Sat, 1/22/11, Ton Roosendaal <t...@blender.org> >> wrote: >> > >> >> From: Ton Roosendaal <t...@blender.org> >> >> Subject: Re: [Bf-committers] Removing auto >> registration >> >> To: "bf-blender developers" <bf-committers@blender.org> >> >> Received: Saturday, January 22, 2011, 9:57 AM >> >> 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 >> >> >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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
