Gnash - 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: |
Benjamin Wolsey <bwy> |
Mon 08 Oct 2007 12:11:51 PM UTC, comment #42: All confirmed, good work ! Feel free to commit. |
Sandro Santilli <strk> |
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).
|
Benjamin Wolsey <bwy> |
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> |
Mon 08 Oct 2007 09:20:46 AM UTC, comment #39: ** $Id: qt/qnamespace.h 3.3.7 edited Feb 22 2006 $
|
Sandro Santilli <strk> |
Mon 08 Oct 2007 09:07:31 AM UTC, comment #38: Which particular keys should I press/release for a good test ?
|
Sandro Santilli <strk> |
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). |
Benjamin Wolsey <bwy> |
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.
|
Sandro Santilli <strk> |
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:
|
Benjamin Wolsey <bwy> |
Mon 24 Sep 2007 02:10:55 AM UTC, comment #34:
SPACE character seems correct here.
|
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:
|
Benjamin Wolsey <bwy> |
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> |
Fri 21 Sep 2007 01:51:25 AM UTC, comment #31:
|
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
|
Sandro Santilli <strk> |
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.
|
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.
|
Benjamin Wolsey <bwy> |
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.
|
Zou Lunkai <zoulunkai> |
Fri 14 Sep 2007 06:56:44 AM UTC, comment #26: I'm talking about the keycode returned by Key.getCode().
|
Benjamin Wolsey <bwy> |
Fri 14 Sep 2007 06:48:30 AM UTC, comment #25: Ben, please don't "presume" , test rather :)
|
Sandro Santilli <strk> |
Fri 14 Sep 2007 06:46:38 AM UTC, comment #24: Oops. You're right, they don't return the same keycode.
|
Benjamin Wolsey <bwy> |
Fri 14 Sep 2007 06:37:58 AM UTC, comment #23:
|
Zou Lunkai <zoulunkai> |
Fri 14 Sep 2007 06:33:59 AM UTC, comment #22:
|
Sandro Santilli <strk> |
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:
|
Benjamin Wolsey <bwy> |
Fri 14 Sep 2007 03:39:15 AM UTC, comment #20: Let me sum up our problems:
|
Zou Lunkai <zoulunkai> |
Thu 13 Sep 2007 11:01:00 AM UTC, comment #19:
|
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.
|
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.
|
Benjamin Wolsey <bwy> |
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.
|
Benjamin Wolsey <bwy> |
Wed 12 Sep 2007 12:19:24 PM UTC, comment #15: Key process model in my brain:
|
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).
|
Sandro Santilli <strk> |
Wed 12 Sep 2007 11:54:30 AM UTC, comment #13: Changing interface was a bit of a disaster.
|
Benjamin Wolsey <bwy> |
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> |
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.
|
Benjamin Wolsey <bwy> |
Wed 12 Sep 2007 08:29:43 AM UTC, comment #10: Todo still:
|
Benjamin Wolsey <bwy> |
Wed 12 Sep 2007 06:31:17 AM UTC, comment #9: I think for 100% task close we need automated testcase.
|
Sandro Santilli <strk> |
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. |
Benjamin Wolsey <bwy> |
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> |
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).
|
Benjamin Wolsey <bwy> |
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> |
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.
|
Sandro Santilli <strk> |
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.
|
Benjamin Wolsey <bwy> |
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.
|
Benjamin Wolsey <bwy> |
Tue 11 Sep 2007 07:56:31 AM UTC, comment #1: That also means that:
|
Benjamin Wolsey <bwy> |
Tue 11 Sep 2007 07:50:15 AM UTC, original submission:
Actionscript has two main methods for keyboard handling:
|
Benjamin Wolsey <bwy> |
Depends on the following items: None found
Items that depend on this one: None found
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 Complete | 20% | 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 Complete | 70% | 20% | |
2007-09-12 | strk | Carbon-Copy | - | Added zoulunkai | |
2007-09-12 | bwy | Percent Complete | 30% | 70% | |
2007-09-12 | strk | Assigned to | None | 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 | Status | None | In Progress | |
Percent Complete | 0% | 30% | |||
2007-09-11 | bwy | Attached File | - | Added more_chars.patch, #13916 | |
Attached File | - | Added out.swf, #13917 |
Powered by Savane 3.13-02a9.
Corresponding source code
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.