Reported in version: HG 2.0 Reported for operating system, platform: All, All
Comments on the original bug report:
On 2007-12-20 12:35:24 +0000, Christian Walther wrote:
Some time ago, I set out to implement the new SDL 1.3 keyboard API for X11, based on my previous work in this area (Bug 319). At some point I got stuck on a problem that I could not find a satisfactory solution for. In the hope that someone else can help me out, here is a patch that contains what I arrived at.
In its present state, the code mostly works with the western keyboard layouts I have tested, but most likely fails miserably as soon as input methods are involved. Specifically, GetLayoutKey() turned out to be less straightforward to implement than I had hoped. What I need there, for character keys, is basically a static mapping from X11 KeySyms to one-character (unicode) key names (static because KeySyms correspond 1:1 to our concept of a "layout key code"). But I have been unable to find an elegant way of doing this. Xutf8LookupString(), which I'm using now, is inappropriate because it takes into account dead keys and input methods (and probably messes up the XIC that I'm currently borrowing from the first window). XLookupString() works, but only for Latin-1 characters. XKeysymToString() produces ASCII strings, not single characters. The only correct way I can imagine is to have a giant look-up table containing all thousands of KeySyms. I'm hoping some X11 expert (which I am not) has a better idea here... or perhaps the API we designed is just unimplementable and needs to be revised.
Other unfinished or questionable points:
I haven't implemented generation of text events because I don't understand what's going on in the commented-out SDL 1.2 code with saved_keysym.
I've resurrected the X11_KeyRepeat() function from SDL 1.2. Was there a particular reason why it was removed?
Due to what I wrote in http://article.gmane.org/gmane.comp.lib.sdl/34610, I can't use SDL_iconv() for UTF-8/SDLKey conversions (it's probably a bit heavy-weight anyway). Instead I've taken fragments of the integrated SDL_iconv() implementation and put them into the functions encodeUtf8() in SDL_keyboard.c and decodeUtf8() in SDL_x11keyboard.c. This should probably be centralized somewhere.
On 2007-12-20 12:36:31 +0000, Christian Walther wrote:
They have 819 entries in common, 377 are in the former only, 46 in the latter only, and 84 conflict. Unable to judge the quality of the mappings (particularly with respect to the conflicting entries, most of which appear in the Korean range (0x0Exx)), I decided to go with the numbers and choose the former. In the hope that this helps avoid a mess, I integrated that file as-is, except for the addition of the license header (which lives in a central file in the X.org source) and modification of #include statements.
So, here is an updated patch that should now work properly in all cases (after some minor tweaking, I expect). Bob, what do you think about this?
Some of the caveats mentioned above still stand:
No text inputs are generated yet.
encodeUtf8() still needs to be reconciled with SDL_iconv() (but decodeUtf8() is gone).
On 2009-02-16 20:53:07 +0000, Sam Lantinga wrote:
I think this is resolved in the current SDL 1.3 code. Christian, can you confirm?
On 2009-02-22 12:17:33 +0000, Christian Walther wrote:
I haven't followed SDL development for a while (as you may have noticed), but from a cursory glance at the current source, it looks like it. imKStoUCS.c, which was the solution for the original problem, is still used.
The text was updated successfully, but these errors were encountered: