Word in Hebrew and Wine
wine-devel at shemesh.biz
Thu Jul 3 04:30:32 CDT 2003
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
>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
>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.
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
More information about the wine-devel