[Bf-committers] ESC Key handling proposal

[Brecht Van Lommel]

A more general solution is indeed needed here. The ESC key should go
through the typical event handling loop before being used to cancel a
running job, so that SCREEN_OT_animation_cancel, the operator to hide
the file browser, and similar operators can catch it before anything
else does.

I think this could be implemented relatively easily with a "cancel
job" operator at the window level bound to the ESC key. This can then
set the G.is_break global if any jobs are running. That global should
really be removed and the cancel signal passed to a specific job, but
maybe that's more work than you want to invest in this.

When moving this to an operator, a problem is that blender_test_break
needs to catch the ESC event when the event handling loop is skipped
due to some heavy job blocking the main thread. Actually
blender_test_break should get removed, it's used now just for point
cache and dynamic paint baking. The proper solution is to make those
non-blocking using the jobs system, but if I remember correctly that's
problematic because editing/drawing the scene will mess up the bake,
so that may not be so simple.

The quick solution would be to add a separate global variable for
blender_test_break, and clearly mark blender_test_break as being
intended for operations that block the main thread.

On Fri, May 24, 2013 at 1:07 AM, PabloVazquez.org <venomgfx at gmail.com> wrote:
> As a user, I've ran into this many times before as well.
>
> But not only on Alt+A, also while file browsing for example. Pressing Esc
> to close the file browser would stop my render. Is pretty common that while
> doing long renders you keep working on the .blend file doing other stuff.
>
> There might be other cases, maybe a more generic way to deal with this is
> needed?
>
>
> --
> Pablo Vazquez
> CG Artist - Blender Foundation Certified Trainer
> Twitter: @venomgfx <http://twitter.com/venomgfx>
> Blender Network: blendernetwork.org/pablovazquez
> Email: contact at pablovazquez.org
> Website: pablovazquez.org <http://www.pablovazquez.org>
>
>
> On Thu, May 23, 2013 at 10:21 PM, Daniel Genrich <daniel.genrich at gmx.net>wrote:
>
>> Hey,
>>
>> I've come upon a very weird problem when using the ESC key.
>>
>> When I am e.g. baking a fluid simulation, then press alt-a (3dview
>> animation playback loop) and then press "ESC" the animation playback in
>> the 3dview is stopped BUT also is the fluidsim bake. This happens with
>> alot of stuff too, like renderer, compositor, etc.
>>
>> They all have in common that they rely on the "G.is_break" variable
>> which is set when ESC is pressed (wm_event_system.c line 3111).
>> In interface_templates.c (line 2817) we have a nice differentiated
>> function which could serve as example.
>>
>> In the moment it is very easy to loose valueable work by accidently
>> pressing ESC because you want to stop the 3dview animation playback .
>>
>> My proposal for wm_event_system.c line 3111:
>>
>> if(ESC_PRESSED)
>> {
>>      if(animation_is_running)
>>      {
>>          WM_jobs_stop(CTX_wm_manager(C), CTX_data_scene(C), NULL); // or
>> event B_STOPANIM in do_jobs_running()
>>      }
>>      else
>>      {
>>          G.is_break = TRUE;
>>      }
>>
>>
>>
>> Looking forward to your feedback,
>> Daniel
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers