Handling key typed events in GRIN?
The other day I saw a remote control that's going to be shipped with a combo Google TV/Blu-ray player, and it got me to thinking that it might be worthwhile to clean up the key typed event handling in GRIN. I've got two questions for the community. Would anyone be interested in seeing this happen? And, is anyone using what's there now?
In Java, there's a distinction between key typed events, and key pressed/released events. Key pressed is what's guaranteed to be present in Blu-ray, and represents a raw VK_ code from the remote control. For key pressed/key released, there's no distinction between "a" and "A" - a low-level handler has to track VK_SHIFT and VK_A and such. VK codes work fine for a typical remote control, but once you start having modifier keys (like shift) and letters, you really need key typed events. I assume that Blu-ray players with such an input device will generate key typed events, though doing this is optional in the Blu-ray spec.
GRIN's remote control handling is really built around a remote control, and the VK_ events. There's some incomplete stuff in there about key typed, but AFAIK it's never been used by anyone. About the only thing I can think of where you'd want to use key typed events would be for text entry, which would have to be as some sort of text entry facility that includes a virtual keyboard, and doing that was beyond the scope of GRIN.
That said, GRIN does impose a threading model where input events are queued, and delivered in the animation thread. The incomplete key typed support that's there now was meant to allow subclassing to route key typed events through this queue. Looking back at what's there now, I think it's more complex and confusing than it needs to be. AFAIK it's never been used.
What I think I'd like to do is rip out the little bit of key typed stuff that's there now, and replace Show.handleKeyTyped(com.hdcookbook.grin.input.RCKeyEvent) with Show.handleKeyTyped(java.awt.event.KeyEvent). Show would just add the KeyEvent to the same queue that handles commands; when the KeyEvent pops out the other end of the queue (in the animation thead), it could look for a key_typed handler attached to the current segment. A key_typed handler would be much like the key_pressed and key_released handler, except it wouldn't specify which keys, and it would call a new method, Director.notifyKeyTyped(KeyEvent). The reason for this is that to do anything meaningful with a key event, you need to call into code with the event instance somewhere; the Director seems like the place to do it.
If someone wanted to make a text input controller, it could subclass the key_typed handler, and thus get the key events without going through the director. I'm thinking that a GRIN extension someday could contain a text_entry controller that's attached to a text feature. Actually writing such a text_entry controller would be a moderately large project, since it would need to include a virtual keyboard.
I'm not thinking of doing the text_entry controller myself, but I thought it would be good to put the basic plumbing in GRIN, since the events do need to flow through GRIN's command queue.
Any thoughts? Objections? Anyone think they might use this someday?