taskGnash - The GNU Flash player - Tasks: task #7292, Sort out keyboard handling

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #7292: Sort out keyboard handling

Submitter:  Benjamin Wolsey <bwy>
Submitted:  Tue 11 Sep 2007 07:50:15 AM UTC
   
 
Should Start On:  Tue 11 Sep 2007 12:00:00 AM UTC Should be Finished on:  Tue 11 Sep 2007 12:00:00 AM UTC
Category:  None Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  bwy Percent Complete:  80%
Open/Closed:  Open Effort:  0.00

Jump to the original submission

Tue 09 Oct 2007 12:54:56 PM UTC, comment #43: 

Point 2 from Comment #35 is fixed (we were adding gnash code, not SWF keycode, to the index of keys down).

It still won't work for non-US keyboards, where several keycodes can be on one key. If I press shift and '(', then release shift, keycode for '(' will be stuck marked as down.

This should be fixed by fixing point 1, however.

Point 3 seems to be a problem either with the default font or getting the glyphs, because -va shows that characters like ä are added to a string as expected, but not displayed.

Benjamin Wolsey <bwy>
Group Member
Mon 08 Oct 2007 12:11:51 PM UTC, comment #42: 

All confirmed, good work ! Feel free to commit.

Sandro Santilli <strk>
Group Member
Mon 08 Oct 2007 12:06:06 PM UTC, comment #41: 

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)

Benjamin Wolsey <bwy>
Group Member
Mon 08 Oct 2007 09:43:56 AM UTC, comment #40: 

If a keyboard event is registered, the kde gui is obviously sending the wrong code for the key, which is most likely an error in working out which gnash::key::code corresponds to the key press. I'll have time to look at it in a couple of hours.

Benjamin Wolsey <bwy>
Group Member
Mon 08 Oct 2007 09:20:46 AM UTC, comment #39: 

** $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.

Sandro Santilli <strk>
Group Member
Mon 08 Oct 2007 09:07:31 AM UTC, comment #38: 

Which particular keys should I press/release for a good test ?
And what codes should I expect ?

Sandro Santilli <strk>
Group Member
Tue 25 Sep 2007 11:50:20 AM UTC, comment #37: 

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)

Benjamin Wolsey <bwy>
Group Member
Mon 24 Sep 2007 03:26:35 PM UTC, comment #36: 

I dunno which of these changes, but I guess latest, broke the key control of the standalone player. I verified ^Q doesn't work anymore to quit, others should be documented by gnash --help.
All only have effect with CTRL pressed.

Sandro Santilli <strk>
Group Member
Mon 24 Sep 2007 02:09:37 PM UTC, comment #35: 

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.

Benjamin Wolsey <bwy>
Group Member
Mon 24 Sep 2007 02:10:55 AM UTC, comment #34: 


>{32, 32, 32}, // SPACE = 32

SPACE character seems correct here.

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


right, keycodes of these keys probably wrong.
testing results here:
{33, 49, 33},  // EXCLAM = 33
{34, 222, 34}, // DOUBLE_QUOTE = 34
{35, 51, 35},  // HASH = 35
{36, 52, 36},  // DOLLAR = 36


> 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.


multi keycodes for the same key or multi keycodes for the same character?
We don't have problems with the first one. Note 'character' is the entry index to the codeMap, not 'key'.  I understand the same key could produce multi characters(with the help of modifiers), in this case we need to analyze the keys and modifiers to get the correct character. At least, analyzing modifiers is always needed for SDL.






Zou Lunkai <zoulunkai>
Sun 23 Sep 2007 06:49:29 PM UTC, comment #33: 

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.

Benjamin Wolsey <bwy>
Group Member
Fri 21 Sep 2007 09:00:54 AM UTC, comment #32: 

Just to make things interesting, I'd also like to see the new support I added to libbase for LIRC integrated into the keyboard. The current implementation exposes the LIRC (remote control device) as an extension, but this is merely a thin wrapper of the base class. Since a remote is basically the same a a keyboard, for the best functionality it should work within the keyboard handlers. You can use lircemu (on our wiki under tools) to test this with.

Rob Savoye <rsavoye>
Group administrator
Fri 21 Sep 2007 01:51:25 AM UTC, comment #31: 


> 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.


Zou Lunkai <zoulunkai>
Wed 19 Sep 2007 06:32:07 AM UTC, comment #30: 

MovieTester has to be considered a separate GUI, so you may want to have a static table for MovieTester too. 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.

Sandro Santilli <strk>
Group Member
Wed 19 Sep 2007 04:52:14 AM UTC, comment #29: 

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?

Zou Lunkai <zoulunkai>
Fri 14 Sep 2007 12:19:37 PM UTC, comment #28: 

That makes perfect sense to me. Especially if it's in ascii order, it would be very easy to map from the gui to the table index.

The only thing it doesn't handle is isDown(), but I don't have any ideas about how to do that. How to work out what other keycodes are on the key on that particular keyboard? I'd guess that can be left till later though.

Benjamin Wolsey <bwy>
Group Member
Fri 14 Sep 2007 11:57:06 AM UTC, comment #27: 

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?

Zou Lunkai <zoulunkai>
Fri 14 Sep 2007 06:56:44 AM UTC, comment #26: 

I'm talking about the keycode returned by Key.getCode().

I don't have a French keyboard to test, but on mine (German), keycode always corresponds to a particular characters, wherever they are on the keyboard. That's why I'm very sure ; and : will return the same code, but it would be useful if someone could test it.

It just means you can't be sure from testing shift which of two or three characters the keycode is from, but perhaps I'm missing the point.

Benjamin Wolsey <bwy>
Group Member
Fri 14 Sep 2007 06:48:30 AM UTC, comment #25: 

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 ?

Sandro Santilli <strk>
Group Member
Fri 14 Sep 2007 06:46:38 AM UTC, comment #24: 

Oops. You're right, they don't return the same keycode.

The shift example holds, though, and on a French or Belgian keyboard, ; and : are on different keys without shift but will presumably return the same keycode.

Benjamin Wolsey <bwy>
Group Member
Fri 14 Sep 2007 06:37:58 AM UTC, comment #23: 


>> , 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.



Zou Lunkai <zoulunkai>
Fri 14 Sep 2007 06:33:59 AM UTC, comment #22: 


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


If what you said is true (, and . returning same keycode) then the above is not true, as they are on different keys on the US keyboard

Sandro Santilli <strk>
Group Member
Fri 14 Sep 2007 06:29:01 AM UTC, comment #21: 

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.


Benjamin Wolsey <bwy>
Group Member
Fri 14 Sep 2007 03:39:15 AM UTC, comment #20: 

Let me sum up our problems:
we have 3 types of key code:
swfcode, keyCode and  ascii code.

(1) different physical keys may share the same swfcode.
eg. KEY_0 and Numeric_keypad_0.
(2) different physical keys may also share the same ascii code.
eg. KEY_LEFT and KEY_RIGHT, both of the key ascii value are zero.
(3) different physical keys may also share the same key code.
eg. A and Lower case A, both of the key codes are 65. ascii codes are 97 and 65.

But for (3), in order to input a lower case key, we need to hold the SHIFT key down. We actually pressed two keys.  So far as I see, for every single key press, the key code is unique. Can you confirm this, bwy?


Zou Lunkai <zoulunkai>
Thu 13 Sep 2007 11:01:00 AM UTC, comment #19: 


> 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.


Zou Lunkai <zoulunkai>
Thu 13 Sep 2007 10:49:57 AM UTC, comment #18: 

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

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


I like this point:) It works to me, and no interface need to be changed. And should be speed efficient.

bwy, is there any problem with this way?






Zou Lunkai <zoulunkai>
Thu 13 Sep 2007 08:30:48 AM UTC, comment #17: 

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)

Benjamin Wolsey <bwy>
Group Member
Wed 12 Sep 2007 12:43:43 PM UTC, comment #16: 

I don't see the point in mapping ascii, since it's either the same or 0 in two easy-to-define ranges, and that can be handled in Key.cpp without any problem at all.

However, using the file out.swf attached, if I press ü (an extended ascii value) the pp displays ü and returns the correct ascii value. So we need to handle swfcode above 128 whether ascii is mapped or calculated.

Otherwise I have nothing against doing it like that.

It could be SWF version dependent, of course.

Benjamin Wolsey <bwy>
Group Member
Wed 12 Sep 2007 12:19:24 PM UTC, comment #15: 

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?







Zou Lunkai <zoulunkai>
Wed 12 Sep 2007 11:57:47 AM UTC, comment #14: 

+1 for reusing key::code (or we'll need to rewrite many places).
Of course 'make check' will tell if anything goes wrong, assuming you have all the dependencies for building and running tests (please get them)

Sandro Santilli <strk>
Group Member
Wed 12 Sep 2007 11:54:30 AM UTC, comment #13: 

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).

Benjamin Wolsey <bwy>
Group Member
Wed 12 Sep 2007 09:38:43 AM UTC, comment #12: 

Added zou in Cc as I belive he's working on testcases for this.

Sandro Santilli <strk>
Group Member
Wed 12 Sep 2007 09:35:33 AM UTC, comment #11: 

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?

Benjamin Wolsey <bwy>
Group Member
Wed 12 Sep 2007 08:29:43 AM UTC, comment #10: 

Todo still:

1. tests
2. Add gnash::key::swfcode map to gnash.h

Benjamin Wolsey <bwy>
Group Member
Wed 12 Sep 2007 06:31:17 AM UTC, comment #9: 

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...

Sandro Santilli <strk>
Group Member
Wed 12 Sep 2007 06:26:12 AM UTC, comment #8: 

I think this is more or less complete with the attached patch. Dead keys still don't work, but editable text works and getAscii() works.

(file #13923)

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 07:56:25 PM UTC, comment #7: 

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

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 07:51:05 PM UTC, comment #6: 

This patch works. It passes a unicode (uint32_t) all the way to getAscii(), which converts it to an int and returns it (UTF-8 matches ASCII extended up to 255 characters).

I've only changed gtk.cpp, so the other guis (and build, if they're enabled) will break if this patch is applied.

I don't want to apply this until someone has had a look at it. I don't want to introduce security problems.

(file #13921)

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 04:03:48 PM UTC, comment #5: 

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).

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 03:50:27 PM UTC, comment #4: 

I guess we need an handle to the Gui from the core lib. This is not the only case in which we need that.
Alternatively, the Gui will need to communicate both ascii and code when sending key events (seems simpler).

Sandro Santilli <strk>
Group Member
Tue 11 Sep 2007 03:46:40 PM UTC, comment #3: 

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.


Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 01:09:18 PM UTC, comment #2: 

I've got as far as adding the missing keycodes to gnash.h (apart from tilde, which I forgot) and making gtk-gui pass a fuller range of keys.

The attached patch contains those changes and stops making shift add a character to the string in edit_text_character.cpp.

But although the correct key codes are passed (can be verified with the attached swf), they aren't displayed. The movie also displays the typed string in the top left corner, which it's not supposed to do.

getAscii still doesn't work at all, either.



(file #13916, file #13917)

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 07:56:31 AM UTC, comment #1: 

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.

Benjamin Wolsey <bwy>
Group Member
Tue 11 Sep 2007 07:50:15 AM UTC, original submission:  

Actionscript has two main methods for keyboard handling:

1. getCode(), which returns a code based on the US keyboard for each key pressed, and

2. getAscii(), which returns the ASCII value of the character returned by key combination (after shift etc has been taken into account) for standard ASCII characters.

For non-US keyboards, however, where symbols are in a different place, getCode() also returns a different value depending on key combination:

US keyboard: ':' and ';' are on the same key. The key returns code 186, getAscii() is 58 or 59 depending on shift status.

German keyboard: ',' and ';' are on the same key. Key returns code 188 or 186, ascii 44 or 59, depending on shift status.

Letters with accents seem to return the same code for getCode and getAscii, and conform to extended ascii as shown in:
http://www.idevelopment.info/data/Programming/ascii_table/PROGRAMMING_ascii_table.shtml

ö: 246
Ö: 214
ñ: 241
æ: 230
ø: 248
Ø: 216

These are probably relatively easy to handle.

Gnash doesn't work with very many keys at all at present. It may be more on a US keyboard.

Benjamin Wolsey <bwy>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #14114:  kde_keyboard.patch added by bwy (4KiB - text/x-patch)
file #14029:  kde_keyboard_handling.patch added by bwy (4KiB - text/x-patch)
file #14028:  keyevent.swf added by bwy (526B - application/x-shockwave-flash)
file #13939:  xkeytst.as added by bwy (248B - application/octet-stream)
file #13934:  gnashkeymap added by bwy (4KiB - application/octet-stream)
file #13923:  complete_text_entry.patch added by bwy (10KiB - text/x-patch)
file #13921:  ascii_patch.patch added by bwy (7KiB - text/x-patch)
file #13916:  more_chars.patch added by bwy (5KiB - text/x-patch)
file #13917:  out.swf added by bwy (304B - application/x-shockwave-flash)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rsavoye (Posted a comment)
  • -email is unavailable- added by zoulunkai (Posted a comment)
  • -email is unavailable- added by strk
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by bwy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-10-08 bwy Attached File- Added kde_keyboard.patch, #14114
    2007-09-25 bwy Attached File- Added kde_keyboard_handling.patch, #14029
    2007-09-25 bwy Attached File- Added keyevent.swf, #14028
    2007-09-24 bwy Percent Complete20% 80%
    2007-09-14 bwy Attached File- Added xkeytst.as, #13939
    2007-09-13 bwy Attached File- Added gnashkeymap, #13934
    2007-09-12 bwy Percent Complete70% 20%
    2007-09-12 strk Carbon-Copy- Added zoulunkai
    2007-09-12 bwy Percent Complete30% 70%
    2007-09-12 strk Assigned toNone bwy
    2007-09-12 bwy Attached File- Added complete_text_entry.patch, #13923
    2007-09-11 bwy Attached File- Added ascii_patch.patch, #13921
    2007-09-11 bwy StatusNone In Progress
        Percent Complete0% 30%
    2007-09-11 bwy Attached File- Added more_chars.patch, #13916
        Attached File- Added out.swf, #13917

    Back to the top

    Powered by Savane 3.13-5190.
    Corresponding source code