Dmitry Timoshkov wrote:
Actually Alexandre didn't like that patch, and I reworked it and sent to wine-patches as "Add support for CP_UNIXCP". If you could try it and report whether it allows you to type with UTF-8 locale, it would be nice.
Compiling it as we speak. Please bear in mind that knowing which keyboard locale the current keymap belongs to is important. I'm not sure we can afford to give the locale info from the keyboard layouts just yet.
Once this patch is commited, all the base for keyboard layout support should be in place, and implementing kbd layout APIs should be a straightforward enough task.
I hope. Like I said - the above point is blocking a major application for me.
Regarding the current implementation, I don't think that it's over complicated. We have to cope with different virtual key code layouts and should make an attempt to detect current X keyboard layout in order to assign correct keyboard map, and report correct VK_xxx key events.
I'm in agreement thus far. I (sadly) don't think the rows of keymap definitions can be tossed out the door just yet.
The CP_UNIXCP patch simplifies a bit current scheme by removing the codepage field from layout tables, which should avoid converting X key events to unicode using wrong code page,
Well, that may be the case, and yet I think we will need to know the LANGUAGE for the keyboard anyhow.
and therefore make it possible to make international keyboard input work even if we have made a mistake while detecting an X keyboard layout.
That's actually not what I'm worried about. The last time that the keyboard detection algorithm question was raised, the concensus was that while the current algorithm is sub-ideal, there is no practical need to replace it.
What exactly part of it you see could be simplified, and how?
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