[Bf-committers] Global undo & running python scripts

[joeedh]

Willian Padovani Germano wrote:

> Ton Roosendaal wrote:
>
>> A related issue was reported in the tracker about running python  
>> scripts (with GUI). Can one of our python team members say something  
>> about the correct circumstances to detect whether a running script 
>> can  be closed and safely restarted after Undo?
>
>
> Hi,
>
> A well behaved script would work fine with close / restart, but there 
> are a few things we still have to add, for example to restart them 
> automatically, if needed.  But that could be a little cumbersome.  I 
> prefer to investigate a little before commenting.  I didn't find the 
> bug report you mention, Ton.  Could someone tell me which one it is?
>
> We keep a separate dictionary (accessible with module 
> Blender.Registry) for as long as Blender is running, so scripts can 
> save config / current state data in dictionaries saved in this 
> "registry dictionary".  I still have (will try before 2.37) to make 
> Blender save these as small data files for each script when saving 
> files or at least when leaving -- and then reload this config data on 
> startup.  To "tell" scripts that they will be closed can be done 
> easily by adding a new callback: there are already draw, event and 
> button event ones, we can add a quit cb so scripts can leave with some 
> elegance.
>
> Not closing the scripts because of undo might prove a better idea 
> indeed, Campbell.  All data in a script's gui is Python data.  And 
> scripts with guis should always check Blender data to ensure it is 
> still available before they redraw anything, so changes shouldn't be a 
> problem, Ton.  Maybe it's possible to keep scripts open, since they 
> can keep track of relevant changes themselves if well coded.
>
> Jonathan Merritt mentions using callbacks in favor of scriptlinks.  
> Both have their uses and Ton and the bpython team agree that the 
> callbacks are needed for interactive use, they are part of the plan 
> for the new event system and something might even be added to the new 
> transform system being worked on, let's see (and discuss) later.
>
> It's not hard at all to code them, it's basically what the 
> Blender.Draw.Register function does already.  But probably it's better 
> not to do it before the new event and transform code is in place.  I'd 
> say this is a good time to discuss, possibly using the wiki.
>
One possibility would be to have each Blender python object type update 
the pointer to it's Blender equavilant on UNDO.  But this might be a 
little difficult to do. . .

joeedh