I've found one error that was obviously responsible for the shift-a problem. Corrected patch attached (with AsciiTilde correction too).

Ascii code for Shift should be 0

Other keys would be:

Ctrl 17     0
F3   114    0
'    222    39
"    222    34
1    49     49
!    49     33


(file #14114)

** $Id: qt/qnamespace.h   3.3.7   edited Feb 22 2006 $

gui/kde.cpp:189: error: 'Key_tilde' is not a member of 'Qt'

        Key_AsciiTilde = 0x7e,
        Key_Dead_Tilde          = 0x1253,
        Key_Atilde = 0x0c3,
        Key_Ntilde = 0x0d1,
        Key_Otilde = 0x0d5,
        Key_atilde = 0x0e3,
        Key_ntilde = 0x0f1,
        Key_otilde = 0x0f5,

( I guess we want the first one, right ? )

Applying that change still kde doesn't seem to cope well with key presses. Pressing 'a' triggers the message

'Key pressed. Flash code 0. Ascii code 0.'

Pressing 'SHIFT-a' it gets to:

'Key pressed. Flash code 16. Ascii code 16.'

I belive it should be 'Key XXX pressed', btw.

Patch here for kde to clean up and extend keyboard handling, which I haven't tested or built. Perhaps a kde user can apply, test, and if necessary correct it (using attached keyevent.swf for instance).

(file #14028, file #14029)

I've added and  corrected keycodes up to the end of extended ascii. The problems that remain are:

1. Key '8' on my keyboard should return 56 57 219 for isDown(), whatever modifier is also pressed. This is because 8, ( and [ are on the same key. At present, gnash core can't tell which other characters are on the same key, so this needs work.
 
2. If I release shift before a character key, it makes isDown() ignore the release of the character key: so <shift> <A>, <release shift>, <release A> leaves 65 permanently marked as isDown.

3. Extended ascii characters aren't displayed, although getAscii() and getCode() work fine. The problem is chr(Key.getAscii).

4. Dead keys (not modifiers: http://en.wikipedia.org/wiki/Dead_key makes it clear what I mean) don't work at all. This is probably easy enough from the gui end (they aren't passed at all at the moment), but the pp handles them very weirdly: the code returned when the key is released seems to have no relationship to the key pressed. My dead key caret (^) returns keycode for R when it's released. I'm not sure that we want to copy this behaviour. It seems silly, and I can't see what would depend on that kind of response.

I can finish off zou's excellent key map now I'm back. If I haven't completely misunderstood it, a few of the keycodes in the map (middle column) are wrong. Ones like these, for instance:

  {32, 32,  32}, // SPACE = 32
  {33, 33,  33}, // EXCLAM = 33
  {34, 34,  34}, // DOUBLE_QUOTE = 34
  {35, 35,  35}, // HASH = 35
  {36, 36,  36}, // DOLLAR = 36

Double_quote (") should be {34, 222,  34}, shouldn't it? Well, you have about 18 hours before I change anything to tell me if I've got it wrong.

I'll clean up gtk (can be tidied up a lot now the list is in ascii order) and probably upload patches for other guis that I can't build and test.

Key.isDown() still won't work with non-US keyboards, since it should return the keycode for every character on a key: there are up to three different keycodes for some keys on a German keyboard. I also managed to break it with certain key press and release orders, but will experiment with that more once the codes are fixed.

> The only use is letting
> test runners simulate a key press. How to refer to the key which
> needs to be pressed is up to you.

Right, this is what we are doing in cvs-head.

Key.getCode(), Key.getAscii(), Key.isDown() are correctly supported now.

Adding support for new keys should be easy with cvs-head:
(1) add a name for the new key to key::code
(2) add the Flash specific codes to key::codeMap
(3) map the physical key to the name in key::code in GUI(function xxx_to_gnash_key()).
The core need not to be touched.

Currently, GTK_GUI supports most key, but still need some work for other GUIs(fltk, kde, fb). I am familar to SDL, so I can take care of this one.

BTW, I need to back to actions order in the coming days.

I attempted a new design with the static table for GUI_SDL. It looks good so far.

The problem I have now is to konw the compile time GUI selection. I need to update some files only when GUI_SDL is defined(including MovieTester). But seems not all files could aware GUI_xxx is defined or not.

strk said GUI_xxx is defined in Makefile(gui/Makefile as I found), not in config.h.  Any reason for this?

There should be a static table between all keyCodes, keySwfCode and keyAsciiCodes. And all of them are in the range [0, 255]. So if we build a 255X3 table for the Flash defined relationship(documented and undocumented), it should be big enough to support all keys and keyboards.

And the next thing we need to do is mapping all OS keys in the GUI level to the entries of this table. We record the entry index for each key, and we will be able to tell what are the swfcode, keycode and asciiCode for this key.

Does it make sense?

Ben, please don't "presume" , test rather :)
Btw, are we talking about the key code as seen by a flash movie or by a key code inspector of the OS ?

>> , and . (no shift) return the same keycode

If this is true, that's not good news.

, returns 188
. returns 190
they are two different keys here.

Confirmed.  ' and " are on the same key, both return 222(key code) but different ascii value. It's not a problem.

I'm not sure I've understood you correctly, but I don't think that's right either:

, and . (no shift) return the same keycode but are on different keys for most people. ' and " (with shift) both return 222 (also on different keys)

The keycode is unique to a key on the standard/international US keyboard, but not for other keyboards.

> OK, I confirmed there are more key codes(returned by
> Key.getCode())than swf defined key codes.

Not exactly, just more than swf-key-codes documented in Alexis' reference. Maybe there are some undocumented swf key codes(eg. key codes greater than 128). Need more hacks:)

I'll do some checks based on your map.

I've attached a map that shows most of the unique combinations of swfcode, keycode and ascii. As explained in the file, it's not enough to pass any single one of those, because for each one there are cases when a single code could map to several of another code without a reliable way of telling which one.

There are 147 combinations of 3 excluding extended ascii, which could add up to another 128, depending on how many characters flash accepts.

The only way of dealing with it that occurs to me is passing our own value from the gui that maps on to only one of those unique combinations.

If swfcode extended to 255, ascii wouldn't need to be there. Is there any way of checking this?

Alternatively, we could use swfcode up to 255 internally for deriving ascii but only use up to 126 for movies.



(file #13934)

Key process model in my brain:

step1. user press a physical key on keyboard.

step2. GUI.pollKey() retruns a translated key code which is GUI dependent.

step3. GUI map the translated key code to swf defined key code(gnash::key::swfcode, currently it is gnash::key::code, which is wrong).

step4.1. If user call Key.getCode(), then Gnash map swf defined key code to gnash::key::code.
step4.2. If user call Key.getAscii(), then Gnash map swf defined key code to gnash::key::asciicode(to be added).

to strk:
Not that bad, no much things to be changed and we can still keep all the interfaces untouched.

to bwy:
I did some work on that part before, but interrupted by some other things and lacking of testcases.

Here was my prototype,  see if it works:

typedef struct
{
uint8 key_swf_code;
uint8 key_code; gnash::key::code
uint8 key_ascii_code;
} keyCode;


keycode
table[] =
{
{0,  key::INVALID, 0},
{1,  key::LEFT, 0},
{2,  key::RIGHT, 0},
{3,  key::HOME, 0},
{4,  key::END, 0},
{5,  key::INSERT, 0},
{6,  key::DELETEKEY, 0},
{8,  key::BACKSPACE, 0},
{13, key::ENTER, 0},
{14, key::UP, 0},
{15, key::DOWN, 0},
{16, key::PGUP, 0},
{17, key::PGDN, 0},
{18, key::TAB, 0},
{19, key::ESCAPE, 0},

        ...  // unfinished work.
}

As you see, both Key.getCode() and Key.getAscii() are based on swf defined key code. There are just about 128 swf defined key codes. So I guess not all ASCII values(supposed to be 256) are used. And even not all physical keys are used for SWF files, IIRC.

The above table would cost 128*3 bytes memory, not a big deal for gnash:)

Any comments?

Changing interface was a bit of a disaster.

New suggestion is to add gnash::swfkey namespace with keys 0-32 mapped. Above that it should correspond to ascii value so is easy to calculate.

Guis would map to gnash::swfkey::code.

getAscii() would not need a separate map, as the first 19 keys have ascii 0, the rest are the same as swfkey.

getCode is more difficult. Best way is probably a swfkey to getcode map: a lookup table?

What else needs gnash::key::code map? I have only found event_id.h. Zou suggests this would need swfkey as well, so I don't see why gnash::key is needed on its own at all, as long as Key.getCode can look up the proper value.

(That would mean we could change gnash::key to mapping swfkey and forget the new ::swfkey namespace).

It looks like gui keyboard events should map to a different set of keycode from how it is set up now (swf-defined, 'swfcode'). Non-character events are assigned codes from 0-19, 32-126 reportedly correspond to ascii values.

http://sswf.sourceforge.net/SWFalexref.html#swf_condition

key.getCode() returns a different code (already mapped in gnash.h)
key.getAscii() returns the ascii value of the key.

Things to test:

1. Movies respond to swfcode, not keycode.
2. What about text entry in a movie character?
3. What about ascii values over 128 (extended ascii)?
4. Is it true that swfcode doesn't extend to 255 chars?

I think for 100% task close we need automated testcase.
See if MovieTester interface needs to be extended in order
to test this. It should allow to press virtual keys...

Well, I'd assumed other guis also passed key events on, but apparently they don't.

Sending the ascii from the gui was what I was thinking of doing. Would there be a case for sending utf-8 from the gui so it can either be converted to ascii for compatibility or, if required, to let gnash handle character sets that flash can't? (I don't know if that would be possible or sensible).

Committed a change that adds more or less all keycodes and gets gtk (but not other guis) to pass them when pressed.

I experimented with getAscii(). It is possible to obtain the Ascii value (server/asobj/Key.cpp) in almost all cases by testing for ko->key_is_down(196) [shift] and, if it were available, whether caps lock is toggled and then adding or subtracting a number that depending on the keycode.

However, there is at least one case where this won't work:

" (doublequote) and ' (apostrophe) return code 222. On practically every keyboard but the US one, both need the shift button, so there is no way to check whether the code 222 is a " or a ' by looking at shift.

That also means that:

Ü and \      (220) or
Û and (      (219) or
Ý and )      (221)

return the same keycode, even when they are never on the same key.