Skip to main content

Handling key typed events in GRIN?

5 replies [Last post]
billf
Offline
Joined: 2004-02-13
Points: 0

Hi everyone,

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?

Cheers,

Bill

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Bill Foote

Interesting about the Apple II emulator!

I agree, it seems like keyboards might start becoming more relevant in Blu-ray.
It's not hard to add support into GRIN. It wouldn't be quite identical
to how remote control keys are handled -- the current mechanism doesn't have
a way of passing in the key event. With only (really) the arrows, the numbers,
and on a good day the colors, it worked pretty well to just have a different
command_rc_handler for each key, and that kept the mechanism simpler.

That said, it's not hard to invent a mechanism that passes the key events
along. Unless I hear sentiments to the contrary, I'll probably implement
something along the lines described at the beginning of the thread. Thinking
about it a bit more, a GRIN extension that makes a virtual keyboard available
when needed isn't all that hard, either, and it'd make a nice sample.

On 9/11/10 Sep 11 10:55 PM, bd-j-dev@mobileandembedded.org wrote:
> I've been looking into keyboard support for BD-J recently because I found out that the hardware players I'm coding for support USB keyboards - the Sony BDP-S370/470/570 models. I believe Sony added keyboard support because the players can access online video services like Netflix, Youtube, etc. I don't know if the keyboard will work with BD-J as the only BD-J stuff I've done has been with GRIN and not the direct BD-J API.
>
> I have found another BD-J project that implemented a virtual keyboard for an Apple II BD-J emulator. The source is GPL so the code for the virtual keyboard could be reused and distributed. The project is here: http://code.google.com/p/umjammer/ and the Apple II emulator is vavi-games-appleii-bdj.
>
> Would it be difficult for GRIN to have keyboard support in the same way that it supports remote key codes, only using the key typed events instead of key pressed?
>
> It would seem that this would be the "next big thing" as more and more hardware players add support for keyboards - a requirement for advanced features like video streaming services or even (someday) a web browser.
> [Message sent by forum member 'nahie']

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

thiagovespa
Offline
Joined: 2006-09-03
Points: 0

I think this kind support is a "must have" feature...

A BD-Live chat a application without a keyboard support is a pain experience.

Is there a way that I can help?

nahie
Offline
Joined: 2010-09-11
Points: 0

I've been looking into keyboard support for BD-J recently because I found out that the hardware players I'm coding for support USB keyboards - the Sony BDP-S370/470/570 models. I believe Sony added keyboard support because the players can access online video services like Netflix, Youtube, etc. I don't know if the keyboard will work with BD-J as the only BD-J stuff I've done has been with GRIN and not the direct BD-J API.

I have found another BD-J project that implemented a virtual keyboard for an Apple II BD-J emulator. The source is GPL so the code for the virtual keyboard could be reused and distributed. The project is here: http://code.google.com/p/umjammer/ and the Apple II emulator is vavi-games-appleii-bdj.

Would it be difficult for GRIN to have keyboard support in the same way that it supports remote key codes, only using the key typed events instead of key pressed?

It would seem that this would be the "next big thing" as more and more hardware players add support for keyboards - a requirement for advanced features like video streaming services or even (someday) a web browser.

billf
Offline
Joined: 2004-02-13
Points: 0

(It looks like the gateway from the e-mail list to the web forum is broken again... Sorry for the duplicate to some.)

Interesting about the Apple II emulator!

I agree, it seems like keyboards might start becoming more relevant in Blu-ray.
It's not hard to add support into GRIN. It wouldn't be quite identical
to how remote control keys are handled -- the current mechanism doesn't have
a way of passing in the key event. With only (really) the arrows, the numbers,
and on a good day the colors, it worked pretty well to just have a different
command_rc_handler for each key, and that kept the mechanism simpler.

That said, it's not hard to invent a mechanism that passes the key events
along. Unless I hear sentiments to the contrary, I'll probably implement
something along the lines described at the beginning of the thread. Thinking
about it a bit more, a GRIN extension that makes a virtual keyboard available
when needed isn't all that hard, either, and it'd make a nice sample.

billf
Offline
Joined: 2004-02-13
Points: 0

I submitted this as RFE 217 in the issues database, in case anyone wants to track progress.

Cheers,

Bill