This patch makes the wm.progress_* bpy methods pump the message queue.

This patch makes the wm.progress_update bpy methods pump the message queue.

Results are:

* Users can cancel scripts with Esc
* User input is ignored until the script finishes (except Esc)
* Blender's window can be moved, minimised etc. while the script is running
* On Windows, pumping avoids the "Not Responding" state

Scripts which don't call the progress_update methods (e.g. UI panels) are not affected by these changes.

[brechtvl, 2013-10-10 16:06:07]

Shouldn't this be an API function that scripts can call, to see if escape was
pressed? That way the script can do proper cleanup instead of leaving things in
a broken state.

Some sort of generic function on operators to check if they should be cancelled
while doing a heavy operation would make sense. If we later decide to run
operators in threads to entirely avoid blocking the interface, then that
function could keep working.

[brechtvl, 2013-10-10 16:09:06]

Also, dropping events is problematic. Users often press keys faster than the
tools, and this can happen even if the operator runs relatively fast.

[Artfunkel, 2013-10-10 16:23:13]

Thanks Brecht.

> Shouldn't this be an API function that scripts can call, to see if escape was
> pressed? That way the script can do proper cleanup instead of leaving things
in
> a broken state.

In my scripts I wrap everything in a try/finally block where the finally block
performs cleanup. It's easier and more reliable than constantly polling a
function.

> Also, dropping events is problematic. Users often press keys faster than the
> tools, and this can happen even if the operator runs relatively fast.

This is a good point, but if an operator executes that fast then surely it
shouldn't be using the progress_update system in the first place?

[brechtvl, 2013-10-10 17:31:13]

On 2013/10/10 16:23:13, Artfunkel wrote:
> Thanks Brecht.
> 
> > Shouldn't this be an API function that scripts can call, to see if escape
was
> > pressed? That way the script can do proper cleanup instead of leaving things
> in
> > a broken state.
> 
> In my scripts I wrap everything in a try/finally block where the finally block
> performs cleanup. It's easier and more reliable than constantly polling a
> function.

I'd rather have it explicit instead of having these functions throw exceptions,
I don't think scripters would expect them to do this, and some operations may be
quite difficult to revert on cancel so I think there needs to be manual control
over when you can cancel and when you can't.

> > Also, dropping events is problematic. Users often press keys faster than the
> > tools, and this can happen even if the operator runs relatively fast.
> 
> This is a good point, but if an operator executes that fast then surely it
> shouldn't be using the progress_update system in the first place?

The same function can be fast with some data and slow with other data, for
example mesh editing tools working on small or big meshes. It's quite difficult
to predict in general.

Events should never be thrown regardless if the script takes a short or long
time. If it catches a modified key down event but misses key up, Blender will
assume that modifier key is still pressed, and you get hanging modifier keys.

[Artfunkel, 2013-10-11 10:20:18]

Removed input blocking and Esc to cancel

[Artfunkel, 2013-10-11 10:28:55]

In more detail:

Adding a "script cancelled" function to check will require some more thought,
plus I'd like to hear some more opinions on its merit vs. a keyboard interrupt,
so for now I've removed the whole feature.

You're totally right on the problems with blocking input in general, but there
is still one scenario where we should consider doing it: if the window has been
resized, clicks on outdated screen image won't go land they were intended to
when Blender wakes up and refreshes its layout.