librelist archives

« back to archive

Help needed implementing keyup/keydown

Help needed implementing keyup/keydown

From:
MenTaLguY
Date:
2009-11-11 @ 04:38
So I've got a branch up on github which has an initial sketch of keyup/ 
keydown, only implemented on Linux for now. 

My problem: I don't seem to have a way to filter out key repeats with 
GTK. My recollection from work years ago had been that when a key was 
held down, you'd get a sequence of events like this: 

GDK_KEY_PRESS 
GDK_KEY_PRESS 
GDK_KEY_PRESS 
GDK_KEY_PRESS 
GDK_KEY_PRESS 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 

That's fine, and I could filter out the duplicate KEY_PRESS events 
easily enough for keydown. However, what I'm actually seeing is this: 

GDK_KEY_PRESS 
GDK_KEY_RELEASE 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 
GDK_KEY_PRESS 
GDK_KEY_RELEASE 

So there's not a good way in this case to distinguish autorepeats from 
rapid keypresses. :/  Does anyone know of a workaround? 

Thanks, 
-mental 

Re: Help needed implementing keyup/keydown

From:
Cecil Coupe
Date:
2009-11-11 @ 04:59
Perhaps there's a config setting (in a maze of X config files). I'm
running mostly stock Ubuntu 9.04 so I probably can't shed light on the
problem.
--Cecil

On Tue, 2009-11-10 at 23:38 -0500, MenTaLguY wrote:
> So I've got a branch up on github which has an initial sketch of keyup/ 
> keydown, only implemented on Linux for now. 
> 
> My problem: I don't seem to have a way to filter out key repeats with 
> GTK. My recollection from work years ago had been that when a key was 
> held down, you'd get a sequence of events like this: 
> 
> GDK_KEY_PRESS 
> GDK_KEY_PRESS 
> GDK_KEY_PRESS 
> GDK_KEY_PRESS 
> GDK_KEY_PRESS 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> 
> That's fine, and I could filter out the duplicate KEY_PRESS events 
> easily enough for keydown. However, what I'm actually seeing is this: 
> 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> GDK_KEY_PRESS 
> GDK_KEY_RELEASE 
> 
> So there's not a good way in this case to distinguish autorepeats from 
> rapid keypresses. :/  Does anyone know of a workaround? 
> 
> Thanks, 
> -mental 
> 

Re: Help needed implementing keyup/keydown

From:
MenTaLguY
Date:
2009-11-11 @ 06:06
On Tue, 2009-11-10 at 21:59 -0700, Cecil Coupe wrote:
> Perhaps there's a config setting (in a maze of X config files). I'm
> running mostly stock Ubuntu 9.04 so I probably can't shed light on the
> problem.

Turns out it's a bug in the X server.  I've gone ahead and implemented
things assuming a correctly working X server for now, but I'll still
need some folks to implement keyup/keydown on Windows and OSX.  It
should be a relatively simple matter of making sure that
shoes_app_keydown and shoes_app_keyup are called with the right
arguments at the right times.

-mental

Re: Help needed implementing keyup/keydown

From:
i5m
Date:
2009-11-11 @ 17:20
My thoughts (not worth a lot!) on keyup and keydown on Window and OSX


On Wed, Nov 11, 2009 at 6:06 AM, MenTaLguY <mental@rydia.net> wrote:

> It should be a relatively simple matter of making sure that
> shoes_app_keydown and shoes_app_keyup are called with the right
> arguments at the right times.
>
> -mental
>

I just had to quote that for "It should be relatively simple" ;-)

Anyway, had a quick look at the cocoa.m file and for starters the whole key
bit is very similar to gtk.c so coupled with this post on stackoverflow:


http://stackoverflow.com/questions/275088/how-do-i-collect-key-input-in-a-video-game-style-cocoa-app


<http://stackoverflow.com/questions/275088/how-do-i-collect-key-input-in-a-video-game-style-cocoa-app>it
should hopefully be "relatively simple" to implement on OSX using Mental's
work on gtk.c as a basis.

On Windows, I'm struggling a bit more: there are already cases setup for
WM_KEYDOWN and WM_KEYUP so I would have thought they would be the
appropriate places to link to shoes_app_keyup, etc, rather than using a
bunch of IF statements under WM_SYSKEYDOWN or under WM_CHAR. But I haven't
had any luck so far - not that that in itself is surprising.

I.e. a stab in the dark:

 case WM_KEYDOWN:
     //comment out below for now
     //app->os.altkey = false;

  switch(w)
  {
case VK_RIGHT:{shoes_app_keydown(app, w); } break;
case VK_LEFT:{shoes_app_keydown(app, w) ;} break;
case VK_UP:{ shoes_app_keydown(app, w) ;} break;
case VK_DOWN:{shoes_app_keydown(app, w) ; } break;
default: break;
  }
  break;

This builds and doesn't crash. And a simple app such as the keypress one in
the manual modified with keydown works kind of:

The Up and Down arrow keys cause it to crash
Pressing the left arrow key returns "18"
Pressing the right arrow key returns "19"

I really don't know what I'm doing. Just trying to learn.



Regards,

i5m


-----------------------
i5m.co.uk
GPG Key: 0xA18A602B

Re: Help needed implementing keyup/keydown

From:
MenTaLguY
Date:
2009-11-11 @ 21:30
On Wed, 2009-11-11 at 17:20 +0000, i5m wrote:

> Anyway, had a quick look at the cocoa.m file and for starters the
> whole key bit is very similar to gtk.c so coupled with this post on
> stackoverflow:
> 
> 
> 
http://stackoverflow.com/questions/275088/how-do-i-collect-key-input-in-a-video-game-style-cocoa-app
> 
> 
> it should hopefully be "relatively simple" to implement on OSX using
> Mental's work on gtk.c as a basis.

The main tricky thing to keep in mind is that keyup/keydown should
always return the key *without* modifiers.  In particular, even though
keypress might return e.g. :shift_enter, keyup/keydown would still
return "\n".

-mental

Re: Help needed implementing keyup/keydown

From:
i5m
Date:
2009-11-12 @ 14:14
Bit more progress on the Windows front. See commits here:

http://github.com/i5m/shoes/commit/1a95aab2be9062c9a3242c7f4f8892735dfd04c3
http://github.com/i5m/shoes/commit/0cf7ec09bbfb4d3524f8de5a882ca7801000d67a

It's not exactly right yet. But hopefully not too far off. I  created this
simple Shoes app to test:

http://gist.github.com/232905

(don't laugh too much)

And:

* Modifier keys such as CTRL and ALT don't get reported for Keyup and
Keydown, which I believe is desired. This seems to come by default, i.e. by
leaving code out rather than having to code this in (so more by luck than
skill).
* All character keys come through as capitals.
* If you hold a key down, the keypress field flashes to indicate keypress.
Keydown stays solid, correctly changes when keypress up occurs.

I guess props must go to Mental for making it "relatively simple" to hook in
the shoes_app_keyup and shoe_app_keydown functions. Maybe ashbb can finish
off what I've started? Or at least verify I've not broken anything in the
process?



Regards,

i5m


-----------------------
i5m.co.uk
GPG Key: 0xA18A602B


On Wed, Nov 11, 2009 at 9:30 PM, MenTaLguY <mental@rydia.net> wrote:

>
> The main tricky thing to keep in mind is that keyup/keydown should
> always return the key *without* modifiers.  In particular, even though
> keypress might return e.g. :shift_enter, keyup/keydown would still
> return "\n".
>
> -mental
>
>

Re: Help needed implementing keyup/keydown

From:
Dan and Norine Simpson
Date:
2009-11-23 @ 13:49
+1: simple, uniform, and portable labels

On Mon, Nov 23, 2009 at 12:56 AM, MenTaLguY <mentalguy@gmail.com> wrote:

> On Nov 22, 6:56 am, Satoshi Asakawa <ash...@gmail.com> wrote:
> > Hi all,
> >
> > Revised keyup/keydown and non-repeating keydown for Windows.
> > Now, the sequence of events we would expect to see from
> > alt + b would be something this:
> >
> >  keydown '\x12'   # when alt-key pressed, return raw code
> >  keydown 'B'      # when b-key pressed, return raw code
> >  keypress :alt_b  # return logical character code
> >  keyup 'B'        # when b-key released, return raw code
> >  keyup '\x12'     # when alt-key released, return raw code
>
> Hm.  Before pulling, I'd like to see keydown and keyup return the
> *lower case*
> characters.  Also, I think :left_alt would be better than a raw key
> code.  I
> think it's best for portability if we don't pass raw key codes to
> shoes apps.
>
> -mental
>