"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:I was thinking of one of two options. Unfortunetly, both require us to know each keyboard layout we support (though, not necessarily know exactly).
The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard.
I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection.
I would appretiate it if you tell me if you think this logic is wrong.
I see nothing wrong with your logic after that explanation. Yes, we
do really want to know the language of the current X keyboard layout,
but unfortunately I don't know a way to query this information from X,
and all we have now is only the current layout detection scheme with
LCID attached to each layout.
1. Use the current scheme. LCID is all we really need, IIRC.
2. Use the XKB name
2 will mean that we reduce the keyboard source to a table of names, and their respective language IDs. I.e - "us" means English, "fr" means French, "he" means Hebrew etc. This will probably make adding new keyboard easier (and less error prone), but will ONLY work on XKB. Then again, keyboard selection (also part of the currently missing APIs) will only work on XKB anyways, so wer'e probably going to have to soft-depend on XKB whatever we do.
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
