Re: key press events & holding keys down

[Christopher Howard <christopher howard frigidcode com>]

On 03/19/2012 12:49 PM, Chris Vine wrote:
> On Mon, 19 Mar 2012 20:35:33 +0100
> David NeÄas <yeti physics muni cz> wrote:
> > On Mon, Mar 19, 2012 at 07:25:22PM +0000, Chris Vine wrote:
> > > Are you saying that on your hardware, holding one key down blocks
> > > press and release events for all other keys?  I am not saying you
> > > are wrong, but I find that surprising.
> >
> > IMO Christopher observes this:
> > 1) press A
> > 2) press B while still holding A
> > 3) release B while still holding A
> > You get no auto-repeat key events for A after 3) even though you still
> > hold it.

Thank you, that is the basic idea, although it is more precisely:

1) Press A
2) Press B while while still holding A
* I get no auto-repeat key events for A even though I am still holding it*

I.e., as soon as the second key is pressed (before even being released)
I stop receiving any key press events for the first key.

And, of course, don't forget what I mentioned about the initial delay in
getting any repeating stream of key events.

> > The solution can be either using something more low level(?) or simply
> > *NOT* getting your key events from Gdk key events and ignoring
> > autorepeat altogether.  (This is probably what has been â unclearly â
> > already suggested.)

I'm open minded to any approach that gets me where I want to go. Though,
it seems like the simplest approach would be some (probably low level)
means of just checking whether any particular key is (de-)pressed at
that moment.

> Ah yes, I think that is the actual issue for the OP.  However, the
> question which he asked and to which I responded was "under Gtk+, how
> does one check whether or not any particular keyboard key is currently
> pressed?" and the answer to that is to monitor key press and key
> release events and keep state.

Please note, that precisely I asked how I would go about checking
whether or not a key /is/ currently pressed (i.e., de-pressed). Not
whether or not it /has/ been pressed. It must be possible to do this on
some level because I wrote software in ClanLib a few years ago that did
this using a function provided by ClanLib. (I'm not trying to exalt
ClanLib as a great or better library, I'm just saying that is why I know
it is possible.)

> However, I wouldn't advise abandoning GDK just because his real
> question is something different: it may be better to code the game by
> reference to edge events, that is changes of state, rather than by
> auto-repeat, which was not intended for that purpose.
>
> Chris

So, you mean, receive both key press and key release events, and then
maintain my own tracking of whether or not the key is currently being
held down? Okay, that makes sense to me, provided of course I can be
certain that all key press and key release events are properly reported
to my program (otherwise my internal state my gets screwed) and in the
correct order.

However, the approach I was hoping for, i.e. simply checking the current
"reality" state of a key (whether it is actually pressed down or not)
sounds more convenient. If anyone could tell me how to do that, I would
be grateful.

BTW, in the ClanLib program I did something like so:

code:
----------
// initialize keyboard object
CL_InputDevice keyboard = window.get_ic().get_keyboard();

// ...snip...

// start main loop

/* get_keycode() would check if that key was currently depressed
   Obviously, not a very practical approach for word processing
   or typing into a text box, but simple and quite appropriate
   in, say, a space combat game
*/
if(keyboard.get_keycode(49)) // do something
else if(keyboard.get_keycode(50)) // do something else
else if(keyboard.get_keycode(51)) // do this thing
else if(keyboard.get_keycode(52)) // do that thing

// update graphics, etc.

// end main loop
----------

get_keycode() was a method of CL_InputDevice. From the current API (2.3)
<http://clanlib.org/docs/clanlib-2.3/reference_doxygen/classCL__InputDevice.html>:

quote:
----------
bool    get_keycode (int keycode) const
        Returns true if the passed key code is down for this device.
----------

I'll admit, I haven't looked yet to see how ClanLib does this at the
implementation level, but if there was a similar function in Gdk or Gtk+
or where ever, that would be convenient (regardless of how it was
implemented).

-- 
frigidcode.com
indicium.us