<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt">I have to say when I first read your message for this change , I was surprised.<br>You probably know my objection of the API braking in every release and generally of the <br>attitude of blender as a whole of moving too fast. But I have come to accept that me and blender<br>developers do not agree on how things should work. <br><br>Its theirs software and they can do whatever they want with it. I am just a visitor.<br><br>But this change has me perplexed to say the least. If I understand correctly you basically took<br>another big bug of blender and moved it under the carpet. Blender is very buggy piece of software<br>thats not a secret , we have come to accept this.Its not the first nor the last.<br>But you have to realize that there are 2 kinds of people<br>using blender python. People like me that have been introduced to python before

blender, and people who used python for the first time with blender. Both of them expect to use an API thats relatively easy to use.  Afterall this API is targeting python coders and blender users , not blender developers. And if people did not care about ease of use they will be coding blender in C anyway.  This api is not pythonic at all. Its basically one of the worse python libraries I have used for the same reason that this change has happened. Really bad design. Its powerful yet it looks like a C/C++ library to , and as you can imagine I do not have the biggest appreciation of how C/C++ coders decide to design (if they even bother to) their libraries. Accessing variables on startup is the most standard practice in coding. You cannot go more basic than that. The fact that blender crashes is a blender problem not an API problem. The fact that I can no longer access  variables on startup makes my coding harder.

 Making it harder while offering no advantage. <br>Not to exclude the fact that I had to compromise with storing variables<br>in prop Scenes and have the same issues you describe. <br><br>Even the blender excuse does not stand with my addon because I checked before accessing the prop in the first place.<br>Blender did not crash, at all. And in any case if I did access without checking first then the addon would crash anyway<br>if it could not find the prop. So its just common logic. <br><br>Am I missing here something else ? Is there more to this fix than meets the eye ? <br><br>If not I will have to 100% agree with Gert. And I made a blenderartists thread to see if I am the only one or not on this<br>or maybe a tiny minority<br><br><a

 href="http://blenderartists.org/forum/showthread.php?275749-POLL-Would-u-prefer-if-the-API-was-backward-compatible-and-broke-your-addons-less&p=2265563#post2265563">http://blenderartists.org/forum/showthread.php?275749-POLL-Would-u-prefer-if-the-API-was-backward-compatible-and-broke-your-addons-less&p=2265563#post2265563</a><br><div><span><br></span></div><div>In any case its your decision and I respect that. I will see how I can fix Gyes , or remove it completely from contrib. <br></div>  <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Campbell Barton <ideasman42@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> Blender Foundation Python list <bf-python@blender.org> <br> <b><span

 style="font-weight: bold;">Sent:</span></b> Saturday, 22 December 2012, 9:20<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Bf-python] Addon's can no longer access context on activation.<br> </font> </div> <br>Hi Gert, annoyance for the programming environment being<br>limited/policed is something I can appreciate, but I think you &<br>others underestimate just how flawed this kind of logic is.<br><br>There is NO GUARANTEE the context when an addon loads is the same the<br>next time the addon executes (draws panels, menus, runs an operator -<br>etc).<br>If this assumption is made, it only gives problems.<br><br>Im going to enumerate the ways this may fail, these are not corner<br>cases or contrived examples - users may well do any of these things<br>with regular workflows.<br>By the way, you could replace `scene` with active<br>object/window/screen/mesh.. etc, scene is just a common case.<br><br>* Blender loads -> addon loads

 (stores scene) -> User loads new blend<br>file -> User runs addon operator -> Crash/Unpredicted behavior<br><br>* Blender loads -> addon loads (stores scene) -> User changes active<br>scene -> User runs addon operator -> Unpredicted behavior (why did a<br>tool change the other scene?)<br><br>* Blender loads -> addon loads (stores scene) -> User links in a new<br>scene & switches to it -> User runs addon operator -><br>Crash/Unpredicted behavior<br><br><br>To make it worse, debugging these kinds of issues isnt so easy,<br>crashes wont happen every time, developers may only use simple test<br>cases and not even run into problems too.<br><br><br>>From what I can tell there are only disadvantages in accessing blend<br>file data when loading tools.<br><br>Some alternatives...<br><br>* use a handler to perform actions on file load (doesn't run on<br>linking scenes, but can be made to work for some cases).<br><a

 href="http://www.blender.org/documentation/blender_python_api_2_65_release/bpy.app.handlers.html#bpy.app.handlers.load_post" target="_blank">http://www.blender.org/documentation/blender_python_api_2_65_release/bpy.app.handlers.html#bpy.app.handlers.load_post</a><br><br>* have the tool initialize settings on first execution<br><br>* have a button to initialize settings (maybe a but annoying but<br>consider blender already does this for cloth, fluid & smoke)<br><br><br>This is probably a good time to push for addon-preferences and make it<br>a target for 2.66.<br><br><br>On Sat, Dec 22, 2012 at 2:34 AM, Gert De Roost <<a ymailto="mailto:paleajed@gmail.com" href="mailto:paleajed@gmail.com">paleajed@gmail.com</a>> wrote:<br>> Good day,<br>><br>> I must express my deepest regrets about this new change of "policy" for<br>> script writers.  It means Ill have to equip some of my addons with an<br>> unnecessary "Activate" button the

 user has to click to be able to start<br>> using script functionality.  This way the user starts an operator in which I<br>> can then finally access the scene context.  For example my SelProject addon<br>> relies on showing a pulldown menu with all the objects in the scene.  Since<br>> I check for changes in this through a callback, this menu will always be up<br>> to date, even when a new .blend is loaded.  It enables the user to set<br>> parameters for the addon straight after enabling the addon, instead of first<br>> having to click an "Activate" button.<br>> I dont like script writing "policing" like this new measure does, but power<br>> and possibility to do whatever we want, and leave it up to the script writer<br>> to police/debug his own creation.  Suppose a script accesses the scene<br>> context, then enters a modal loop that does PASS_THROUGH, most certainly the<br>> user could now

 load another .blend and all the information harvested in the<br>> scene context could trigger these same bugs this new measure tries to<br>> prevent, maybe we should stop allowing modal loops?<br><br>Sure there are many other ways to cause problems, Im not so interested<br>to disallow py scripters from shooting themselves in the foot at every<br>moment, but loading addons is such a common case that restricting the<br>context is IMHO a good thing.<br><br>Also consider that we get complaints of 3rd partry addons crashing in<br>our main bug-tracker from time to time, its in our interest to provide<br>a system which is stable and not so error prone, not to mention a<br>system that doesn't annoy users by randomly crashing.<br><br>> Sorry, but Im considering to stop actively adapting my addons from now on as<br>> a form of protest...<br>><br>> Of course I might be mistaking or not be informed well enough, Im open to<br>> discussion but at

 the moment I am quite convinced this is not the way to<br>> go...<br>><br>><br>> Gert.<br>><br>> _______________________________________________<br>> Bf-python mailing list<br>> <a ymailto="mailto:Bf-python@blender.org" href="mailto:Bf-python@blender.org">Bf-python@blender.org</a><br>> <a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank">http://lists.blender.org/mailman/listinfo/bf-python</a><br>><br><br><br><br>-- <br>- Campbell<br>_______________________________________________<br>Bf-python mailing list<br><a ymailto="mailto:Bf-python@blender.org" href="mailto:Bf-python@blender.org">Bf-python@blender.org</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank">http://lists.blender.org/mailman/listinfo/bf-python</a><br><br><br> </div> </div>  </div></body></html>