[Bf-committers] Global undo & running python scripts
joeeagar at prodigy.net
Thu Feb 3 12:58:04 CET 2005
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?
> 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
> 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. . .
More information about the Bf-committers