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

[dimitris chloupis]

I have to agree with you. Thats not necessary because loading those presets back is not 

automatic, the users has to press the restore_history button as is shown in the second link. 

At first the load was automatic , but blender was very buggy with this approach and so
I made it manual. Also this way I gave more power to the user to decide what is loaded
and what is not. But I would love to add the automatic restore back if that was possible. 

The question is do I access on load on the first place. As you can see my access does not
happen in the register function but on my class definition. Actually nothing exiting
happens in my registers and unregisters anyway. Because I find this approach very 
"unpythonic" to do stuff in the register functions and instead I use my own classes.
So this is why I am not sure if 
the issue you refering to is relevant to Gyes or not. Or if Gyes is affected at all. 

If it is, I could try to move everything in the button function but I am not sure if that would be entirely possible. 
And will most certainly make the code uglier and more difficult to understand. 


________________________________
 From: Campbell Barton <ideasman42 at gmail.com>
To: dimitris chloupis <thekilon at yahoo.co.uk>; Blender Foundation Python list <bf-python at blender.org> 
Sent: Thursday, 20 December 2012, 16:04
Subject: Re: [Bf-python] Addon's can no longer access context on activation.
 
From what I can tell you dont even need to access the scene on load.

On Thu, Dec 20, 2012 at 12:55 PM, dimitris chloupis
<thekilon at yahoo.co.uk> wrote:
> No idea what you talking about . No idea how to access bpy.context.scene
> while the addon loads.
>
> my access to bpy.context.scene happens here ->
> https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L67
Quite sure you can replace:
if hasattr(bpy.context.scene , "historybak")==False:
with...
if hasattr(bpy.types.Scene, "historybak")==False:

> and here ->
> https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L622
This will continue to work without problems.

>
> in first case I check whether there is a historybak prop in scene , so there
> is no assumptions here
> and blender has no reason to crash. Because I check if it exists in the
> first place.
> If the prop does not exists it gets created in the process.
>
> in second case the history is restored when the user clicks the button.
>
> In any cases there is no chance that the addon would access non existant
> properties
> because I like to leave nothing to chance ;)
>
> unless you try to tell me something else here that I dont understand
> or I missed a possible scenario . I am all ears :)
>
> ________________________________
> From: Campbell Barton <ideasman42 at gmail.com>
> To: dimitris chloupis <thekilon at yahoo.co.uk>; Blender Foundation Python list
> <bf-python at blender.org>
> Sent: Thursday, 20 December 2012, 14:33
> Subject: Re: [Bf-python] Addon's can no longer access context on activation.
>
> 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
>



-- 
- Campbell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20121220/131da572/attachment.html>