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

[Campbell Barton]

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