On 03/19/2012 12:49 PM, Chris Vine wrote: > On Mon, 19 Mar 2012 20:35:33 +0100 > David Nečas <y...@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
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
