892 2013-11-05 16:41:32 +0100 Newt and Java focus gained and lost events are inconsistent 2013-11-17 04:57:28 +0100 1 1 3 JogAmp Newt windows 1 pc_x86_64 windows RESOLVED FIXED P5 minor --- 879 0 narf_bro sgothel narf_bro --- 0be87f241c0f0b2f5881d9a602ce12378b8e453d --- oldest_to_newest 3276 0 narf_bro 2013-11-05 16:41:32 +0100 Currently I'm unable to rely on the focus listener behaviour. Build: Nov01_2013 2.1.2 If I add a Java FocusListener to the NewtCanvasAWT, focus events behave like this: - focusLost issued correctly when I lose focus - focusGained is sometimes followed by focusLost even though the window retains focus if I click in the window. (steps: click back and forth from in window and out, about 25% of the time you'll get a focusLost after gained even though it still has focus) - focusGained is always followed by focusLost even though the window retains focus if I click on the program in the taskbar. (steps: click away from window, select the window from the taskbar) If I add a Newt WindowListener to the glWindow held by my NewtCanvasAWT, focus events behave like this: - focusLost issued correctly when I lose focus - focusGained issued correctly when I gain focus - focusLost and focusGained issued very quickly back to back with every single click inside the window after focus has been gained. The WindowListener is far more consistent but the back-to-back focusLost/focusGained events make it difficult to trust a focusLost event. Expected: It should not re-issue a lost/gained event on every click inside the window. It should only issue an event when focus is actually gained or lost. Workaround: I use the WindowListener and consider focus "actually" lost if it is not immediately followed by a focusGained. 3322 1 sgothel 2013-11-14 21:42:28 +0100 AWT [ NewtCanvasAWT.GLWindow ]: (Not a bug) The problem about temp. loosing and re-gaining focus is well known and more related how we implement focus traversal between GLWindow and the underlying AWT 'tree'. If the GLWindow requires the focus, we need to give it's AWT component the focus first - then steal it back and transfer it to GLWindow. This allows focus traversal back / forth within the AWT tree, while allowing GLWindow using the focus. We maybe able to review the current code .. hence I keep this bug open as an earmark. Due to a focus traversal change we lately made, maybe it's possible to avoid the focus ping-pong between AWT/GLWindow. But this is a tedious validation process. 3323 2 narf_bro 2013-11-14 21:51:37 +0100 Is it simpler to just not issue the focusGained/Lost events in the case you described, rather than change the underlying functionality? If I have the GLWindow already focused I would not expect that it would issue a lose/regain focus event on every click, since it conceptually never lost focus. As it stands now, if I want to do something simple like shut off sounds in the game when the user clicks away from the window, I cannot reliably use focusGained/Lost, because they issue even if I have clicked within the window. 3335 3 sgothel 2013-11-17 04:57:28 +0100 Fixed w/ fix of Bug 879