Word in Hebrew and Wine

[Dmitry Timoshkov]

"Shachar Shemesh" <wine-devel at shemesh.biz> 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.

> I tried it and it does NOT work. I still get "unrecognized keyboard event".

I'd prefer to see at least a +key,+keyboard,+x11drv,+event log (compressed)
with good description: what exactly doesn't work.

> Please bear in mind that knowing which 
> keyboard locale the current keymap belongs to is important.

Actually that's not important for internal functionality in current limits,
but it's necessary for keyboard layout APIs.

> I'm not sure 
> we can afford to give the locale info from the keyboard layouts just yet.

In future we need to revive LCID for every defined keyboard layout, as
it was some time ago.

> >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.

Yes, that's LCID field for.

> >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.

This will require major revamping of the current code. If you have an idea
or a preliminary patch I'm interested to see it.

>    2. Trap the X events that notify about group changes, and pass them
>       on as Windows messages to applications.

That's a part of the planned keyboard layout support implementation.

>    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.

#3 and #4 are exactly how it's currently implemented.

-- 
Dmitry.