<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>Ok , noted will try to run with the latest blender build and see how I can fix this. <br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div><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> dimitris chloupis <thekilon@yahoo.co.uk>; Blender Foundation Python list <bf-python@blender.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, 20
 December 2012, 16:31<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>On Thu, Dec 20, 2012 at 2:13 PM, dimitris chloupis <<a ymailto="mailto:thekilon@yahoo.co.uk" href="mailto:thekilon@yahoo.co.uk">thekilon@yahoo.co.uk</a>> wrote:<br>><br>> I have to agree with you. Thats not necessary because loading those presets<br>> back is not<br>> automatic, the users has to press the restore_history button as is shown in<br>> the second link.<br>><br>> At first the load was automatic , but blender was very buggy with this<br>> approach and so<br>> I made it manual. Also this way I gave more power to the user to decide what<br>> is loaded<br>> and what is not. But I would love to add the automatic restore back if that<br>> was possible.<br>><br>> The question is do I access on load on the first place. As you can see
 my<br>> access does not<br>> happen in the register function but on my class definition. Actually nothing<br>> exiting<br>> happens in my registers and unregisters anyway. Because I find this approach<br>> very<br>> "unpythonic" to do stuff in the register functions and instead I use my own<br>> classes.<br>> So this is why I am not sure if<br>> the issue you refering to is relevant to Gyes or not. Or if Gyes is affected<br>> at all.<br>><br>> If it is, I could try to move everything in the button function but I am not<br>> sure if that would be entirely possible.<br>> And will most certainly make the code uglier and more difficult to<br>> understand.<br>> ________________________________<br>> From: Campbell Barton <<a ymailto="mailto:ideasman42@gmail.com" href="mailto:ideasman42@gmail.com">ideasman42@gmail.com</a>><br>> To: dimitris chloupis <<a ymailto="mailto:thekilon@yahoo.co.uk"
 href="mailto:thekilon@yahoo.co.uk">thekilon@yahoo.co.uk</a>>; Blender Foundation Python list<br>> <<a ymailto="mailto:bf-python@blender.org" href="mailto:bf-python@blender.org">bf-python@blender.org</a>><br>> Sent: Thursday, 20 December 2012, 16:04<br>><br>> Subject: Re: [Bf-python] Addon's can no longer access context on activation.<br>><br>> From what I can tell you dont even need to access the scene on load.<br>><br>> On Thu, Dec 20, 2012 at 12:55 PM, dimitris chloupis<br>> <<a ymailto="mailto:thekilon@yahoo.co.uk" href="mailto:thekilon@yahoo.co.uk">thekilon@yahoo.co.uk</a>> wrote:<br>>> No idea what you talking about . No idea how to access bpy.context.scene<br>>> while the addon loads.<br>>><br>>> my access to bpy.context.scene happens here -><br>>><br>>> <a href="https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L67"
 target="_blank">https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L67</a><br>> Quite sure you can replace:<br>> if hasattr(bpy.context.scene , "historybak")==False:<br>> with...<br>> if hasattr(bpy.types.Scene, "historybak")==False:<br>><br>>> and here -><br>>><br>>> <a href="https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L622" target="_blank">https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L622</a><br>> This will continue to work without problems.<br>><br>>><br>>> in first case I check whether there is a historybak prop in scene , so<br>>> there<br>>> is no assumptions here<br>>> and blender has no reason to crash. Because I check if it exists in the<br>>> first place.<br>>> If the prop does not exists it gets created in the process.<br>>><br>>> in second case the history is
 restored when the user clicks the button.<br>>><br>>> In any cases there is no chance that the addon would access non existant<br>>> properties<br>>> because I like to leave nothing to chance ;)<br>>><br>>> unless you try to tell me something else here that I dont understand<br>>> or I missed a possible scenario . I am all ears :)<br>>><br>>> ________________________________<br>>> From: Campbell Barton <<a ymailto="mailto:ideasman42@gmail.com" href="mailto:ideasman42@gmail.com">ideasman42@gmail.com</a>><br>>> To: dimitris chloupis <<a ymailto="mailto:thekilon@yahoo.co.uk" href="mailto:thekilon@yahoo.co.uk">thekilon@yahoo.co.uk</a>>; Blender Foundation Python<br>>> list<br>>> <<a ymailto="mailto:bf-python@blender.org" href="mailto:bf-python@blender.org">bf-python@blender.org</a>><br>>> Sent: Thursday, 20 December 2012, 14:33<br>>> Subject: Re:
 [Bf-python] Addon's can no longer access context on<br>>> activation.<br>>><br>>> On Thu, Dec 20, 2012 at 12:09 PM, dimitris chloupis<br>>> <<a ymailto="mailto:thekilon@yahoo.co.uk" href="mailto:thekilon@yahoo.co.uk">thekilon@yahoo.co.uk</a>> wrote:<br>>>> I am the developer of Gyes ( random material and texture generator). The<br>>>> reason why Gyes<br>>>> use bpy.context.scene is to store a property that store presets of<br>>>> randomised materials / textures.<br>>>> I wanted the data to be stored/saved with the blend file and be<br>>>> associated<br>>>> with the scene curently loaded<br>>>> as global scene presets and not specific presets to objects or any other<br>>>> 3d<br>>>> asset.<br>>>><br>>>> I am not sure if removing bpy.context.scene is a good idea in the first<br>>>> place, unless there is
 another way to save<br>>>> , store scene presets together with the blend file. If so , then gladly I<br>>>> will update my addon. But if not , it basically<br>>>> cripples / makes useless my history tool -><br>>>><br>>>><br>>>> <a href="http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/System/Gyes/History-Tool" target="_blank">http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/System/Gyes/History-Tool</a><br>>>><br>>>><br>>>> ________________________________<br>>>> From: Campbell Barton <<a ymailto="mailto:ideasman42@gmail.com" href="mailto:ideasman42@gmail.com">ideasman42@gmail.com</a>><br>>>> To: Blender Foundation Python list <<a ymailto="mailto:bf-python@blender.org" href="mailto:bf-python@blender.org">bf-python@blender.org</a>>; bf-blender<br>>>> developers <<a ymailto="mailto:bf-committers@blender.org"
 href="mailto:bf-committers@blender.org">bf-committers@blender.org</a>><br>>>> Sent: Thursday, 20 December 2012, 4:38<br>>>> Subject: [Bf-python] Addon's can no longer access context on activation.<br>>>><br>>>> Recently I've noticed addons using bpy.context.scene when being<br>>>> imported or in the register() function.<br>>>><br>>>> This is really bad practice and will cause inconsistency if the addon<br>>>> is enabled and a different blend file is loaded.<br>>>> In the worst case accessing a removed datablock can crash which is<br>>>> likely if a datablock is stored as a global variable on activation -<br>>>> object_laplace_lightning.py does this.<br>>>><br>>>> I've changed addon loading so that they only get access to a<br>>>> restricted context which only exposes 'window_manager' - needed for<br>>>> adding
 keymaps.<br>>>><br>>>><br>>>> Accessing other attributes now errors out with...<br>>>><br>>>>  AttributeError: '_RestrictedContext' object has no attribute 'scene'<br>>>><br>>>> The addons distributed with blender don't do this but some contrib<br>>>> addons do, so they will need updating<br>>>> (release/scripts/addons_contrib).<br>>>><br>>>> ----<br>>>>    add_mesh_clusters<br>>>>    gyes<br>>>>    io_atomblend_utilities<br>>>>    io_export_marmalade<br>>>>    io_import_LRO_Lola_MGS_Mola_img<br>>>>    io_import_lipSync_Importer<br>>>>    mesh_edgetools<br>>>>    mesh_fiber<br>>>>    mesh_show_vgroup_weights<br>>>>    node_categories<br>>>>   
 object_laplace_lightning<br>>>>    online_mat_lib<br>>>>    sequencer_extra_actions<br>>>>    space_view3d_quickPrefs<br>>>><br>>>> If any devs want some help updating their addons you can ask on<br>>>> bf-python mailing list, though in all cases I've seen its quite<br>>>> straightforward.<br>>>><br>>>> --<br>>>> - Campbell<br>>><br>>> Access has only been removed on loading the addon.<br>>><br>>> The solution is just not to access presets when the addon loads and<br>>> register()'s,<br>>> during execution you still have regular access to the context<br>>> (operators, panels etc).<br>>><br>>> Since the scene at load time may very well not be the same scene when<br>>> the script executes (if the user loads a new file), whatever changes<br>>> made at load time are likely
 lost.<br>>><br>>> --<br>>> - Campbell<br>>><br>>><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>An instance of random_material_class is created on load here, this is<br>causing the problem, so you can choose to create it at runtime, or to<br>have it not touch context.scene.<br><br><a href="https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L441" target="_blank">https://github.com/kilon/Gyes/blob/master/gyes/random_material_generator.py#L441</a><br><br>Both register and creating an instance of
 random_material_class()<br>happen - both have the same limitation.<br><br>The purpose of register() is so you can unregister(), without it there<br>would be no good way to disable/enable addons.<br><br>I don't understand your second last comment, '''The question is do I<br>access on load on the first place.''' - can you give an example?<br><br>Suggest you get the script running without errors first - think its<br>only a few lines to change, then check on ways to improve.<br><br>-- <br>- Campbell<br><br><br> </div> </div>  </div></body></html>