[Bf-python] Addon's can no longer access context on activation.

[dimitris chloupis]

I have to say when I first read your message for this change , I was surprised.
You probably know my objection of the API braking in every release and generally of the 
attitude of blender as a whole of moving too fast. But I have come to accept that me and blender
developers do not agree on how things should work. 

Its theirs software and they can do whatever they want with it. I am just a visitor.

But this change has me perplexed to say the least. If I understand correctly you basically took
another big bug of blender and moved it under the carpet. Blender is very buggy piece of software
thats not a secret , we have come to accept this.Its not the first nor the last.
But you have to realize that there are 2 kinds of people
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. 
Not to exclude the fact that I had to compromise with storing variables
in prop Scenes and have the same issues you describe. 

Even the blender excuse does not stand with my addon because I checked before accessing the prop in the first place.
Blender did not crash, at all. And in any case if I did access without checking first then the addon would crash anyway
if it could not find the prop. So its just common logic. 

Am I missing here something else ? Is there more to this fix than meets the eye ? 

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
or maybe a tiny minority

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


In any case its your decision and I respect that. I will see how I can fix Gyes , or remove it completely from contrib. 


________________________________
 From: Campbell Barton <ideasman42 at gmail.com>
To: Blender Foundation Python list <bf-python at blender.org> 
Sent: Saturday, 22 December 2012, 9:20
Subject: Re: [Bf-python] Addon's can no longer access context on activation.
 
Hi Gert, annoyance for the programming environment being
limited/policed is something I can appreciate, but I think you &
others underestimate just how flawed this kind of logic is.

There is NO GUARANTEE the context when an addon loads is the same the
next time the addon executes (draws panels, menus, runs an operator -
etc).
If this assumption is made, it only gives problems.

Im going to enumerate the ways this may fail, these are not corner
cases or contrived examples - users may well do any of these things
with regular workflows.
By the way, you could replace `scene` with active
object/window/screen/mesh.. etc, scene is just a common case.

* Blender loads -> addon loads (stores scene) -> User loads new blend
file -> User runs addon operator -> Crash/Unpredicted behavior

* Blender loads -> addon loads (stores scene) -> User changes active
scene -> User runs addon operator -> Unpredicted behavior (why did a
tool change the other scene?)

* Blender loads -> addon loads (stores scene) -> User links in a new
scene & switches to it -> User runs addon operator ->
Crash/Unpredicted behavior


To make it worse, debugging these kinds of issues isnt so easy,
crashes wont happen every time, developers may only use simple test
cases and not even run into problems too.


>From what I can tell there are only disadvantages in accessing blend
file data when loading tools.

Some alternatives...

* use a handler to perform actions on file load (doesn't run on
linking scenes, but can be made to work for some cases).
http://www.blender.org/documentation/blender_python_api_2_65_release/bpy.app.handlers.html#bpy.app.handlers.load_post

* have the tool initialize settings on first execution

* have a button to initialize settings (maybe a but annoying but
consider blender already does this for cloth, fluid & smoke)


This is probably a good time to push for addon-preferences and make it
a target for 2.66.


On Sat, Dec 22, 2012 at 2:34 AM, Gert De Roost <paleajed at gmail.com> wrote:
> Good day,
>
> I must express my deepest regrets about this new change of "policy" for
> script writers.  It means Ill have to equip some of my addons with an
> unnecessary "Activate" button the user has to click to be able to start
> using script functionality.  This way the user starts an operator in which I
> can then finally access the scene context.  For example my SelProject addon
> relies on showing a pulldown menu with all the objects in the scene.  Since
> I check for changes in this through a callback, this menu will always be up
> to date, even when a new .blend is loaded.  It enables the user to set
> parameters for the addon straight after enabling the addon, instead of first
> having to click an "Activate" button.
> I dont like script writing "policing" like this new measure does, but power
> and possibility to do whatever we want, and leave it up to the script writer
> to police/debug his own creation.  Suppose a script accesses the scene
> context, then enters a modal loop that does PASS_THROUGH, most certainly the
> user could now load another .blend and all the information harvested in the
> scene context could trigger these same bugs this new measure tries to
> prevent, maybe we should stop allowing modal loops?

Sure there are many other ways to cause problems, Im not so interested
to disallow py scripters from shooting themselves in the foot at every
moment, but loading addons is such a common case that restricting the
context is IMHO a good thing.

Also consider that we get complaints of 3rd partry addons crashing in
our main bug-tracker from time to time, its in our interest to provide
a system which is stable and not so error prone, not to mention a
system that doesn't annoy users by randomly crashing.

> Sorry, but Im considering to stop actively adapting my addons from now on as
> a form of protest...
>
> Of course I might be mistaking or not be informed well enough, Im open to
> discussion but at the moment I am quite convinced this is not the way to
> go...
>
>
> Gert.
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>



-- 
- Campbell
_______________________________________________
Bf-python mailing list
Bf-python at blender.org
http://lists.blender.org/mailman/listinfo/bf-python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20121222/69c8b195/attachment.html>