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

task #7292: Sort out keyboard handling

Submitted by:  Benjamin Wolsey <bwy>
Submitted on:  Tue 11 Sep 2007 07:50:15 AM UTC  
 
Should Start On: Tue 11 Sep 2007 12:00:00 AM UTCShould be Finished on: Tue 11 Sep 2007 12:00:00 AM UTC
Category: NonePriority: 5 - Normal
Status: In ProgressPrivacy: Public
Percent Complete: 80%Assigned to: Benjamin Wolsey <bwy>
Open/Closed: OpenEffort: 0.00

(Jump to the original submission 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>
Project MemberIn charge of this item.
Mon 08 Oct 2007 12:11:51 PM UTC, comment #42:

All confirmed, good work ! Feel free to commit.

Sandro Santilli <strk>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.

 

Attached Files
file #14114:  kde_keyboard.patch added by bwy (4kB - text/x-patch)
file #14029:  kde_keyboard_handling.patch added by bwy (4kB - 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 (4kB - application/octet-stream)
file #13923:  complete_text_entry.patch added by bwy (10kB - text/x-patch)
file #13921:  ascii_patch.patch added by bwy (7kB - text/x-patch)
file #13916:  more_chars.patch added by bwy (5kB - 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
  • -unavailable- added by rsavoye (Posted a comment)
  • -unavailable- added by zoulunkai (Posted a comment)
  • -unavailable- added by strk
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by bwy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 16 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 08 Oct 2007 12:06:06 PM UTCbwyAttached File-=>Added kde_keyboard.patch, #14114
    Tue 25 Sep 2007 11:50:20 AM UTCbwyAttached File-=>Added kde_keyboard_handling.patch, #14029
    Tue 25 Sep 2007 11:50:19 AM UTCbwyAttached File-=>Added keyevent.swf, #14028
    Mon 24 Sep 2007 02:09:37 PM UTCbwyPercent Complete20%=>80%
    Fri 14 Sep 2007 08:31:20 AM UTCbwyAttached File-=>Added xkeytst.as, #13939
    Thu 13 Sep 2007 08:30:48 AM UTCbwyAttached File-=>Added gnashkeymap, #13934
    Wed 12 Sep 2007 11:54:29 AM UTCbwyPercent Complete70%=>20%
    Wed 12 Sep 2007 09:38:43 AM UTCstrkCarbon-Copy-=>Added zoulunkai
    Wed 12 Sep 2007 08:33:29 AM UTCbwyPercent Complete30%=>70%
    Wed 12 Sep 2007 06:31:17 AM UTCstrkAssigned toNone=>bwy
    Wed 12 Sep 2007 06:26:12 AM UTCbwyAttached File-=>Added complete_text_entry.patch, #13923
    Tue 11 Sep 2007 07:51:05 PM UTCbwyAttached File-=>Added ascii_patch.patch, #13921
    Tue 11 Sep 2007 03:46:40 PM UTCbwyStatusNone=>In Progress
      Percent Complete0%=>30%
    Tue 11 Sep 2007 01:09:18 PM UTCbwyAttached File-=>Added more_chars.patch, #13916
      Attached File-=>Added out.swf, #13917

    Back to the top


    Powered by Savane 3.1-cleanup