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

[Matt Ebb]

Being able to store properties in user preferences for example, would be a
great thing to have in this case (and others). I too have to store global
settings in the scene, because unfortunately there's nowhere else to put
it...


On Thu, Dec 20, 2012 at 11:33 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> On Thu, Dec 20, 2012 at 12:09 PM, dimitris chloupis
> <thekilon at yahoo.co.uk> wrote:
> > I am the developer of Gyes ( random material and texture generator). The
> > reason why Gyes
> > use bpy.context.scene is to store a property that store presets of
> > randomised materials / textures.
> > I wanted the data to be stored/saved with the blend file and be
> associated
> > with the scene curently loaded
> > as global scene presets and not specific presets to objects or any other
> 3d
> > asset.
> >
> > I am not sure if removing bpy.context.scene is a good idea in the first
> > place, unless there is another way to save
> > , store scene presets together with the blend file. If so , then gladly I
> > will update my addon. But if not , it basically
> > cripples / makes useless my history tool ->
> >
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/System/Gyes/History-Tool
> >
> >
> > ________________________________
> > From: Campbell Barton <ideasman42 at gmail.com>
> > To: Blender Foundation Python list <bf-python at blender.org>; bf-blender
> > developers <bf-committers at blender.org>
> > Sent: Thursday, 20 December 2012, 4:38
> > Subject: [Bf-python] Addon's can no longer access context on activation.
> >
> > Recently I've noticed addons using bpy.context.scene when being
> > imported or in the register() function.
> >
> > This is really bad practice and will cause inconsistency if the addon
> > is enabled and a different blend file is loaded.
> > In the worst case accessing a removed datablock can crash which is
> > likely if a datablock is stored as a global variable on activation -
> > object_laplace_lightning.py does this.
> >
> > I've changed addon loading so that they only get access to a
> > restricted context which only exposes 'window_manager' - needed for
> > adding keymaps.
> >
> >
> > Accessing other attributes now errors out with...
> >
> >   AttributeError: '_RestrictedContext' object has no attribute 'scene'
> >
> > The addons distributed with blender don't do this but some contrib
> > addons do, so they will need updating
> > (release/scripts/addons_contrib).
> >
> > ----
> >     add_mesh_clusters
> >     gyes
> >     io_atomblend_utilities
> >     io_export_marmalade
> >     io_import_LRO_Lola_MGS_Mola_img
> >     io_import_lipSync_Importer
> >     mesh_edgetools
> >     mesh_fiber
> >     mesh_show_vgroup_weights
> >     node_categories
> >     object_laplace_lightning
> >     online_mat_lib
> >     sequencer_extra_actions
> >     space_view3d_quickPrefs
> >
> > If any devs want some help updating their addons you can ask on
> > bf-python mailing list, though in all cases I've seen its quite
> > straightforward.
> >
> > --
> > - Campbell
>
> Access has only been removed on loading the addon.
>
> The solution is just not to access presets when the addon loads and
> register()'s,
> during execution you still have regular access to the context
> (operators, panels etc).
>
> Since the scene at load time may very well not be the same scene when
> the script executes (if the user loads a new file), whatever changes
> made at load time are likely lost.
>
> --
> - 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/20121220/f2dc11e8/attachment.html>