Right now, a single app that doesn't keep an InputProcessor thread running is capable of bringing ZPUI down completely. This is because the app InputProcessors are also responsible for global callbacks, so if the thread is stopped/busy, a global callback (more important than anything the app could be doing) will not be processed until that happens. To fix that (and allow the user to i.e. switch to ZeroMenu and then to the main menu), we could probably add one more, the most basic, thread, which would receive the key data first and then re-send it to the input thread that's currently active. We can also probably limit these keypresses to ContextSwitch actions and tie them into, say, the receive_key processing code (as soon as ContextSwitch actions are implemented, check #42 ). Then, we need to test the end result and see how it fares against an intentionally mis-written app.
Right now, a single app that doesn't keep an
InputProcessorthread running is capable of bringing ZPUI down completely. This is because the appInputProcessors are also responsible for global callbacks, so if the thread is stopped/busy, a global callback (more important than anything the app could be doing) will not be processed until that happens. To fix that (and allow the user to i.e. switch to ZeroMenu and then to the main menu), we could probably add one more, the most basic, thread, which would receive the key data first and then re-send it to the input thread that's currently active. We can also probably limit these keypresses toContextSwitchactions and tie them into, say, the receive_key processing code (as soon asContextSwitchactions are implemented, check #42 ). Then, we need to test the end result and see how it fares against an intentionally mis-written app.