Re: key press events holding keys down
On Sun, 18 Mar 2012 20:08:12 -0800 Christopher Howard christopher.how...@frigidcode.com wrote: On 03/16/2012 04:29 PM, Christopher Howard wrote: I control the spacecraft with the arrow keys, which I do by grabbing the GdkEventKey and then checking it against GDK_KEY_Left, GDK_KEY_Right, and so forth. Strictly speaking what I am concerned with is whether or not the key is held down, but this seems to work because the key event gets repeated. However, if one of the arrows is held down, and another arrow is pressed, then it shuts off events for the first arrow. That's bad, of course, because in my game the player may want to hold down two arrows keys at once (e.g., UP for acceleration and LEFT to turn the spacecraft). So... Okay, having got no responses, let me ask the question in a more direct manner: under Gtk+, how does one check whether or not any particular keyboard key is currently pressed? I know this is possible because I used to do it back in my ClanLib days. I see in the Gdk docs that there is a GdkDevice object, but it is not clear to me how to create or utilize this to such an end. Since GtkWidget objects have key-press-event and a key-release-event signals that you can connect to (and from your explanation, clearly you have connected to), you will probably need to explain why these don't do what you want in order to get a meaningful answer. Most people would monitor these in conjunction with gdk_event_get_keyval() or gdk_event_get_keycode() and keep state. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: key press events holding keys down
On 03/19/2012 03:34 AM, Chris Vine wrote: Since GtkWidget objects have key-press-event and a key-release-event signals that you can connect to (and from your explanation, clearly you have connected to), you will probably need to explain why these don't do what you want in order to get a meaningful answer. Most people would monitor these in conjunction with gdk_event_get_keyval() or gdk_event_get_keycode() and keep state. Chris I'm currently attempting to code a simple space combat game. In my game it is possible (quite likely) that two keys will be held down at the same time (especially the up arrow and another arrow) e.g. to turn and to accelerate at the same time. Currently I monitor for key press events as you say; the problem is that key press events are only being generated for the last key that was pressed. So if a user attempts to turn and accelerate at the same time, he will actually only do one or the other, depending on which key he happened to press last. If I could just check whether or not a key is currently depressed, then I could check both keys between a main loop iteration and handle them appropriately. This is precisely what I used to do back when I was using ClanLib, which had a function just for this purpose. An additional problem is that, although key press events do get repeated, they do not get repeated immediately; it seems that there is a brief delay (half a second or so, but noticeable) between the first key press event and the subsequent stream of them. This is the same effect I notice when using a word processor. -- 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
Re: key press events holding keys down
On 03/19/2012 11:02 AM, Chris Vine wrote: On Mon, 19 Mar 2012 09:21:27 -0800 Christopher Howard christopher.how...@frigidcode.com wrote: On 03/19/2012 03:34 AM, Chris Vine wrote: Since GtkWidget objects have key-press-event and a key-release-event signals that you can connect to (and from your explanation, clearly you have connected to), you will probably need to explain why these don't do what you want in order to get a meaningful answer. Most people would monitor these in conjunction with gdk_event_get_keyval() or gdk_event_get_keycode() and keep state. Chris I'm currently attempting to code a simple space combat game. In my game it is possible (quite likely) that two keys will be held down at the same time (especially the up arrow and another arrow) e.g. to turn and to accelerate at the same time. Currently I monitor for key press events as you say; the problem is that key press events are only being generated for the last key that was pressed. So if a user attempts to turn and accelerate at the same time, he will actually only do one or the other, depending on which key he happened to press last. A key remains pressed until a key-release-event for it is received. That is what I meant by 'keep state'. Chris So, you are saying that if I receive a key-press-event, I should artificially generate a key-release-event, which will allow more key-press-events to be generated? How should I go about doing this? -- 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
Re: key press events holding keys down
On Mon, 19 Mar 2012 09:21:27 -0800 Christopher Howard christopher.how...@frigidcode.com wrote: On 03/19/2012 03:34 AM, Chris Vine wrote: Since GtkWidget objects have key-press-event and a key-release-event signals that you can connect to (and from your explanation, clearly you have connected to), you will probably need to explain why these don't do what you want in order to get a meaningful answer. Most people would monitor these in conjunction with gdk_event_get_keyval() or gdk_event_get_keycode() and keep state. Chris I'm currently attempting to code a simple space combat game. In my game it is possible (quite likely) that two keys will be held down at the same time (especially the up arrow and another arrow) e.g. to turn and to accelerate at the same time. Currently I monitor for key press events as you say; the problem is that key press events are only being generated for the last key that was pressed. So if a user attempts to turn and accelerate at the same time, he will actually only do one or the other, depending on which key he happened to press last. A key remains pressed until a key-release-event for it is received. That is what I meant by 'keep state'. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: key press events holding keys down
On Mon, Mar 19, 2012 at 07:25:22PM +, 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. 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.) You only use Gdk key events to get notifications that a key was pressed or released – and update the set of pressed keys. Then you use a timer to regularly observe what keys are in the set of pressed keys. And base the controls processing on what you find in the timer. NOT the Gdk key events themselves. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: key press events holding keys down
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 +, 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: -- boolget_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
