> 1) When X is rendering like mad, it mouse and keyboard events are not
> delivered in a timely manner.
Hmm - o.k. when you have machine overload, you will always lag behind
events. However there are several techniques shown in our demos that will
limit the effects of that situation.
> 2) No way to distinguish between real user keystrokes and typeomatic
> repeat.
LibGGI delivers correctly distinguished Events whenever possible.
Some targets however cannot give correct key-up/down events, like terminfo
which only send pressed keys. LibGGI gives a reasonable translation in that
cases i.e. an KeyDownThenUp Sequence.
> demos and couldn't really understand them from a
> monkey-wants-to-figure-out-if-the-'f'-key-is-pressed standpoint.
Hmm - that's a bit different approach. We have not chosen the "iskeydown"
method, as it encourages polling and is prone to need extensions to arrays
and stuff later.
LibGGI uses an event oriented scheme, sending KeyPress/Release/Repeat Events
whenever Keybaord status changes. If you want to know if key x is down, you
have to keep the state in a variable like this:
int left_is_down=0;
while(ggiEventPoll(vis,emAll,&tv)) {
ggi_event event;
ggiEventRead(vis,&event,emAll);
switch(event.any.type) {
case evKeyPress:
switch(event.key.sym) {
case GIIK_Left:
left_is_down=1;
break;
... other keys
}
break;
case evKeyRelease:
switch(event.key.sym) {
case GIIK_Left:
left_is_down=0;
break;
... other keys
}
break;
}
}
However it usually is more convenient to just act on the found keys
directly.
Cu, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
