Re: Word in Hebrew and Wine

[Shachar Shemesh]

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

--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/