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 <[email protected]> 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: [email protected] > Website: pablovazquez.org <http://www.pablovazquez.org> > > > On Thu, May 23, 2013 at 10:21 PM, Daniel Genrich > <[email protected]>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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
