I think I found what is needed in order to implement my suggested keyboard support. The only drawback is that it requires the use of XKB, which is not a given in all Xservers. Personally, I find it hard to believe that there are many X servers that don't support it (the extension is from 1997).
Anyone has anything to say in terms of policy? Suggestions?
Shachar
Shachar Shemesh wrote:
I was aiming for the following path:
1. Detect current keymap. Try to do that independantly for each keymap group (i.e. - have an array - group0 - US, group1 - IL, group2 - RU). The keys will be stored inside the keyboard map in Unicode. I'm not 100% sure how to do that stage yet, but I do have a relatively non-efficient way of doing that to fall back to, if necessary. 2. Trap the X events that notify about group changes, and pass them on as Windows messages to applications. 3. When an X event arrives, convert the raw virtual key to a raw Windows key, and pass it on. Do not convert to ASCII, ANSI, or any other non-layout information. In essence, the keyboard mapping is not used at this stage at all. 4. When an application asks to convert the raw Windows key to ANSI/Unicode, look up the result in the current keymap.
Saving the conversion to ANSI and back should detach us some way from the current Unix locale. In particular, I want Unicode Windows applications to work, with the same level of non-regard to current locale as they have on Windows.
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
