Key repeat delay

[Whackjack]

I'm working on this input bridge between FengGUI and jME and I found that the key repeating
events coming from jME are quite fast.  Most key presses result in double characters.
Now, there are two solutions:

1) Time the key event as it comes from jME and if it arrives within a certain time frame (< 50ms?)
then the event will be ignored.  Of course it would be set up so that it would behave similar to Windows,
in that there's a small delay before keys are repeated.
The problem with this, however, is that it makes it impossible to forward key events onto the application
if FengGUI doesn't handle it.

2) Alter the Display class in FengGUI so that it will check to see if the last event came within the
time frame and will decide whether or not to act on it.
For instance, in fireKeyPressedEvent(), we would have something to the effect of:

if(System.currTimeMillis() - lastKeyEventTime < 50)
    return true;

We would want to return true still, to let the application know that, yes, the Display class did acknowledge
the event, but didn't act on it.  The same kind of Windows-type delay would be applied.

What do you guys think?

Josh

[Johannes Schaback]

Hey Josh,

I prefer option 1 although I also see advantages in option 2. I see
the need to poll the keyevent according to some timer resolution
(50ms) for jME but I am not sure what effect option 2 could have on
the other key bindings (AWT/JOGL and plain LWJGL) so that I would
suggest to handle all irregularities that are binding dependent in the
specific event handling class.

The bindings (JOGL, LWJGL, jME) have quite a different concept to
handle key events. This is also why I havent gotten the time to
implement the repetition of keys while keeping a key pressed correctly
for LWJGL (I am waiting for our new bug-tracker to become available
before I make that a case).

Johannes

PS: The sourceforge guys still havent approved our fenggui project. It
seems as it takes another day or two.

[Whackjack]

Yeah, I realize now that FengGUI is meant to work JOGL which doesn't have
this key repeating problem that LWJGL does.  I haven't quite figured out if it's
specific to LWJGL or just jME.  If it is just jME, then I concede that the fix
should be in a jME related library and not in core FengGUI code.

This can probably sit on the back burner for now.  It's not really a huge deal.

Thanks, Johannes!


Josh

[Whackjack]

Ah, I think I might have figured out a work around that I can put into FengJMEInputHandler.
Basically, I'll ask the Display object if there is a widget that has focus.  If there is, go ahead
and try to send the event based on the aforementioned delay.  If no widget has focus, I'll
just set the keyHandled flag to false and move on.
Does that sound reasonable?

Josh

[Johannes Schaback]

> Ah, I think I might have figured out a work around that I can put into
> FengJMEInputHandler.
> Basically, I'll ask the Display object if there is a widget that has focus.
> If there is, go ahead
> and try to send the event based on the aforementioned delay. If no widget
> has focus, I'll
> just set the keyHandled flag to false and move on.
> Does that sound reasonable?

Yeah. But is there a way without polling the display whether there is
"focused" widget? The reason is that key shortcuts (like CRTL+S) do
not require a widget with focus because shortcuts are handled by the
global key listener.

Johannes

[Johannes Schaback]

"fire at will" applies on fireKeyPressed()... :)

You do not need to ask the Display whether there is a focused widget.
It is fine to just call fireKeyPressed. The returned boolean can be
neglected until now... it does not consider the fact that key events
need to be intercepted by the global key listener (actually a bug...
but I am still waiting for the new tracker to become alive).

Johannes

On 9/28/06, Johannes Schaback <johannes...@gmail.com> wrote:

[Whackjack]

The more I think about this, the more I'm starting to believe that there isn't
going to be a catch-all solution.  I think the best we could do is provide simple
handlers that will be usable in most circumstances, but would be insufficient
for more advanced applications.

I will probably just have to accept this restriction and create custom handlers
as the need arises.

Josh

[Johannes Schaback]

Hi Josh,

The well-obscured truth is that in the early days of FengGUI (when
historians called in joglui) I expected every app that uses FengGUI to
handle and forward the key and mouse events on its own. After
assembling a few examples and using FengGUI for my own stuff I started
to be annoyed of copying and pasting the same key and mouse handling
routines over and over again. So I encapsulated the routines in a
event helper class that still exists until today.
A relict of the old days can be found in
org.fenggui.example.MouseTestJOGL where I demonstrate the use of
custom mouse and key handlers. Since the helper class talks directly
to the fireXXXEvent methods, there is no way to tell for the developer
whether the mouse click hit a widget or not (because the returned
boolean vaporizes in the according method body of the helper class).
Subsequently, people who do some picking in their scenes dont get
notified whether a click hits a widget or "rays" down in the scene. So
yeah I came to the same conclusion like you.

Johannes

aside: Have you guys tried my TreeWidgetExample yet? :)

On 9/28/06, Whackjack <whac...@gmail.com> wrote: