Re: [Bf-committers] Removing auto registration
Uploaded a patch to the tracker which removes automatic registering but adds a convenience function: http://projects.blender.org/tracker/index.php?func=detail&aid=25809&group_id=9&atid=127 The class list we had before can be avoided by using this api call. def register(): bpy.utils.register_module(__name__) def unregister(): bpy.utils.unregister_module(__name__) ... where __name__ is the python builtin for the module name. If the order is important a more verbose class list can be used as before auto-register was added. This doesn't prevent a more advanced registration function to be written which handles dependencies as Martin suggests, it just means the script author can choose to manually manage registering. - Campbell On Tue, Jan 25, 2011 at 10:24 AM, Tom Edwards wrote: > 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 >> 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.bl
Re: [Bf-committers] Removing auto registration
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 > 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
Re: [Bf-committers] Removing auto registration
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 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 > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Removing auto registration
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
Re: [Bf-committers] Removing auto registration
On Sat, Jan 22, 2011 at 9:28 PM, Martin Poirier wrote: > > > --- On Sat, 1/22/11, Brecht Van Lommel wrote: > >> 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? > > I don't think it's terribly complex either. The fixed type order I propose on > the wiki page seems like it should work (quite easy with automatic register > and simply enough to define for manual). Campbell supposedly has all kinds of > wild cases under hands that fail automatic register, so that's why he was > supposed to look into it and come back with definite cases of failure. > > Martin I don't know the ins and outs of this code but is really looks like someone needs to write up some test cases and do some verification and validation of the registration. If the code passes all the wild cases' tests then we say it is good. This looks like a huge trap for the end programmers and it should not be. If the system does not end up being simple, you guys will end up spending the next few years answering the same questions over and over again. As was pointed out, this is the 'new' blender and it should have a stable api by the time it releases, so now is the time to make changes, if they need to be made. Forcing people to rewrite scrips now is much better than making them do it next year when everyone thought the new system was stable and they have forgotten how to work with the new system because they thought they had all the rewrites done a long time ago. Do what needs do be done now and get it over with. Best, -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Removing auto registration
--- On Sat, 1/22/11, Brecht Van Lommel wrote: > 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? I don't think it's terribly complex either. The fixed type order I propose on the wiki page seems like it should work (quite easy with automatic register and simply enough to define for manual). Campbell supposedly has all kinds of wild cases under hands that fail automatic register, so that's why he was supposed to look into it and come back with definite cases of failure. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Removing auto registration
a small comment if the core developers/ designers of the api can't decide which way is 'right': Don't change what's there. If there is controversy, it probably means there are pros and cons both ways; any change comes with a cost- every script has to be modified to work. In he case of stuff that ships with blender, the py is compatible with the api, but it is a problem for external developers; because now you have an incompatiblity between betas/svn. Even a simple change such as the change from bl_addon_info to bl_info was a bit painful here, since we had to figure a way to keep addons working for animators using betas, and for those of us who build svn (so that we can get bug fixes early). It turned out to be a bit non trivial. When we went to autoregistration , it was a couple days work cleaning scripts, and get rid of setting attributes in autogenerated classes (because they were now getting autoregistered) so code would work. We still run into the occasional code path that has a 'register()' left there that causes a script to raise an exception. Going back to registration would cause similar havoc. I'm not saying, don't do this if it's the right thing, but I am saying it's useful to continue the discussion , and get a real consensus if the problems can be solved. Cutting the gordions knot seems counterproductive *if* things can be made to work cleanly. to sum up my long winded argument : "won't someone please think of the children" ;) On Sat, 2011-01-22 at 17:24 +0100, Ton Roosendaal wrote: > 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- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Removing auto registration
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 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 wrote: > >> From: Ton Roosendaal >> Subject: Re: [Bf-committers] Removing auto registration >> To: "bf-blender developers" >> 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 >> wrote: >> > >> >> From: Ton Roosendaal >> >> Subject: Re: [Bf-committers] Removing auto >> registration >> >> To: "bf-blender developers" >> >> 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. >> >> :) >> >> >> >
Re: [Bf-committers] Removing auto registration
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 wrote: > From: Ton Roosendaal > Subject: Re: [Bf-committers] Removing auto registration > To: "bf-blender developers" > 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 > wrote: > > > >> From: Ton Roosendaal > >> Subject: Re: [Bf-committers] Removing auto > registration > >> To: "bf-blender developers" > >> 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 > >> wrote: > >>> > >>>> Agree panel order shouldn't be a > >>>> factor in this d
Re: [Bf-committers] Removing auto registration
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.orgwww.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 wrote: > >> From: Ton Roosendaal >> Subject: Re: [Bf-committers] Removing auto registration >> To: "bf-blender developers" >> 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 >> 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
Re: [Bf-committers] Removing auto registration
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 wrote: > From: Ton Roosendaal > Subject: Re: [Bf-committers] Removing auto registration > To: "bf-blender developers" > 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 > 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 >
Re: [Bf-committers] Removing auto registration
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.orgwww.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 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
Re: [Bf-committers] Removing auto registration
--- On Mon, 1/17/11, Campbell Barton 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
Re: [Bf-committers] Removing auto registration
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. Though I'm still for auto-registration removal even if its bug free, most likely re-iterating from previous mails. - to me it feels mysterious that blender is operating on classes without being asked & errors don't trace back to authors code. - 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. - it makes internals more complicated we need to support - 3 cases: direct execution, modules and addons. - 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. 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. On Sun, Jan 16, 2011 at 5:02 PM, Martin Poirier wrote: > Having panels in the order they are registered is the issue. > We already discussed that last time. > > Martin > > --- On Sun, 1/16/11, Thomas Dinges wrote: > >> From: Thomas Dinges >> Subject: Re: [Bf-committers] Removing auto registration >> To: "bf-blender developers" >> Received: Sunday, January 16, 2011, 11:54 AM >> Hi, >> regarding UI Panels, the auto registration caused lots of >> order issues >> there. Having panels order in the same way the >> classes are written in >> the python file is not a good method. >> Therefore +1 for revert. >> >> Am 16.01.2011 17:51, schrieb Brecht Van Lommel: >> > Hi all, >> > >> > In november there was already a discussion here about >> python class >> > auto registration, but there was no agreement on the >> issue. So I was >> > asked to try to cut the knot here, and I'm proposing >> to revert to >> > manual registration. >> > >> > On first thought, I prefer auto registration, because >> it corresponds >> > to how I envisioned the API working when doing RNA >> design. But I also >> > think the advantages are quite minor, and I agree >> after reading the >> > discussion that on larger projects it can add more >> confusion. Also, >> > there's a number of bugs and issues with it, which >> haven't been >> > resolved and don't seem like they will anytime soon. >> Solving them will >> > also make the API code more complicated. >> > >> > We could discuss the topic further, but it also seems >> that a certain >> > point this is a matter of preference. Campbell can do >> the commit if >> > there's no objection. >> > >> > Thanks >> > Brecht. >> > ___ >> > 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 > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Removing auto registration
Having panels in the order they are registered is the issue. We already discussed that last time. Martin --- On Sun, 1/16/11, Thomas Dinges wrote: > From: Thomas Dinges > Subject: Re: [Bf-committers] Removing auto registration > To: "bf-blender developers" > Received: Sunday, January 16, 2011, 11:54 AM > Hi, > regarding UI Panels, the auto registration caused lots of > order issues > there. Having panels order in the same way the > classes are written in > the python file is not a good method. > Therefore +1 for revert. > > Am 16.01.2011 17:51, schrieb Brecht Van Lommel: > > Hi all, > > > > In november there was already a discussion here about > python class > > auto registration, but there was no agreement on the > issue. So I was > > asked to try to cut the knot here, and I'm proposing > to revert to > > manual registration. > > > > On first thought, I prefer auto registration, because > it corresponds > > to how I envisioned the API working when doing RNA > design. But I also > > think the advantages are quite minor, and I agree > after reading the > > discussion that on larger projects it can add more > confusion. Also, > > there's a number of bugs and issues with it, which > haven't been > > resolved and don't seem like they will anytime soon. > Solving them will > > also make the API code more complicated. > > > > We could discuss the topic further, but it also seems > that a certain > > point this is a matter of preference. Campbell can do > the commit if > > there's no objection. > > > > Thanks > > Brecht. > > ___ > > 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
Re: [Bf-committers] Removing auto registration
Hi, I think it's premature to take a decision until a registration order that fixes problematic situations has been determined. I even had a proposal for a fixed order that seemed to solve most issues (that I could think of) but never received any comments on it (nor on anything on that page for that matter). http://wiki.blender.org/index.php/User:Theeth/API_Design Such a fixed order is easy to implement with automated registration. Even if we decide that people need to solve the issue themselves, we must tell them how to solve it, not just give them a pat on the back and a good luck. I already raised those points months ago when this discussion started, if anybody had more discussions about that, they certainly didn't make it on this list (some people can't be on irc all the time). Martin --- On Sun, 1/16/11, Brecht Van Lommel wrote: > From: Brecht Van Lommel > Subject: [Bf-committers] Removing auto registration > To: "bf-blender developers" > Received: Sunday, January 16, 2011, 11:51 AM > Hi all, > > In november there was already a discussion here about > python class > auto registration, but there was no agreement on the issue. > So I was > asked to try to cut the knot here, and I'm proposing to > revert to > manual registration. > > On first thought, I prefer auto registration, because it > corresponds > to how I envisioned the API working when doing RNA design. > But I also > think the advantages are quite minor, and I agree after > reading the > discussion that on larger projects it can add more > confusion. Also, > there's a number of bugs and issues with it, which haven't > been > resolved and don't seem like they will anytime soon. > Solving them will > also make the API code more complicated. > > We could discuss the topic further, but it also seems that > a certain > point this is a matter of preference. Campbell can do the > commit if > there's no objection. > > Thanks > Brecht. > ___ > 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
Re: [Bf-committers] Removing auto registration
Hi, regarding UI Panels, the auto registration caused lots of order issues there. Having panels order in the same way the classes are written in the python file is not a good method. Therefore +1 for revert. Am 16.01.2011 17:51, schrieb Brecht Van Lommel: > Hi all, > > In november there was already a discussion here about python class > auto registration, but there was no agreement on the issue. So I was > asked to try to cut the knot here, and I'm proposing to revert to > manual registration. > > On first thought, I prefer auto registration, because it corresponds > to how I envisioned the API working when doing RNA design. But I also > think the advantages are quite minor, and I agree after reading the > discussion that on larger projects it can add more confusion. Also, > there's a number of bugs and issues with it, which haven't been > resolved and don't seem like they will anytime soon. Solving them will > also make the API code more complicated. > > We could discuss the topic further, but it also seems that a certain > point this is a matter of preference. Campbell can do the commit if > there's no objection. > > Thanks > Brecht. > ___ > 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] Removing auto registration
Hi all, In november there was already a discussion here about python class auto registration, but there was no agreement on the issue. So I was asked to try to cut the knot here, and I'm proposing to revert to manual registration. On first thought, I prefer auto registration, because it corresponds to how I envisioned the API working when doing RNA design. But I also think the advantages are quite minor, and I agree after reading the discussion that on larger projects it can add more confusion. Also, there's a number of bugs and issues with it, which haven't been resolved and don't seem like they will anytime soon. Solving them will also make the API code more complicated. We could discuss the topic further, but it also seems that a certain point this is a matter of preference. Campbell can do the commit if there's no objection. Thanks Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
