[Bf-committers] Global undo & running python scripts

[Jonathan Merritt]

Campbell Barton 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?
>>
>> -Ton-
>
> I dont know if its reasionable to ask- but would it be possible not to 
> exit the script at all? At the moment undo takes long enough with 
> large files, re-running all scripts would not make things any faster.
> But this could be a stop gap solution... :)
> - Cam


Commenting purely on some of my own scripts...

I have several scripts (in the Blix distribution) which run "in 
parallel" with the rest of Blender.  They rely on being able to detect 
"changes" in the rest of Blender.  The main example of this is changes 
to the current selection.  Currently, I detect when the current 
selection has changed using a rather crazy hack: I procedurally create a 
new script (from within the first), attach it to the scene "Redraw" 
scriptlink, and then have that second script manually redraw the all of 
the script windows when Blender redraws the scene!  (Yes, it does sound 
like a lot of work!)  It's completely nuts to have to jump through hoops 
like this for very simple interaction.

Having the potential for Blender to re-start scripts in some kind of 
ad-hoc fashion to fit in with the undo system would be a massive spanner 
in the works.  What I think is needed is a "real" callback API from 
Blender providing hooks into the undo system and the rest of the GUI.  I 
would lead the cheer if script links were scrapped forever in favour of 
a more extensive system.

Such a system could take the form of (for example) a Python class which 
is passed to Blender by a function when the script is first run.  The 
class could then override various method callbacks that Blender can 
natively pump events into.   From the Python side, it would look 
something like this:

class MyCallbackHandler(Blender.Callback):
    def selectionChanged(self, ...):
       """Called when the selection in Blender has changed."""

It would also be possible to define a finer-grained set of callback 
classes for specific purposes.  The model would follow something similar 
to Java's "listeners", with perhaps one listener being responsible for 
the scene, another for objects, another for undo events, another for 
mesh data, etc...

-- 
Jonathan Merritt BE(Mech)/BSc
PhD Student - Equine Biomechanics
The University of Melbourne
Veterinary Clinical Centre, Werribee