Word in Hebrew and Wine

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>"Shachar Shemesh" <wine-devel at shemesh.biz> wrote:
>  
>
>>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.
>  
>
I get "unknown key". I'll try to recompile with it and let you know.

>>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.
>  
>
And it is important for getting Word to work with BiDi. All I was trying 
to do is to get this aspect of the API a higher priority.

>>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.
>  
>
That's what I meant. Sorry if I wasn't clear.

>>>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.
>  
>
I have already started collecting the necessary information. It does, 
however, require relying on Xkb. This would also let us let applications 
control the current layout (for that I already have a working code). I 
/THINK/ we can get to a point where we don't need the keyboard lists in 
keyboard.c at all, which means we can support new keyboards with a 
simple line saying "IL is LCID(MAKELANG(LANG_HEBREW, SUBLANG_DEFAULT))".

I still have not started looking at how difficult it would be to be 
softly dependant on Xkb (so that if it's not present, not to support 
Windows keyboard switching). On the whole, however, I'm getting the 
feeling I'm planning work to be done in parallel to you, which sounds 
like a waste of resources. Especially as I may have found a local 
vulenteer to do the actual coding :-). If it makes more sense for you to 
delve into this, let me know and I'll redirect my vulenteer to other 
useful areas of Wine.

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

>>   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.
>  
>
That's not the impression I got, I have to admit. It has been a while 
since I stepped through the code, but I got the impression that Windows 
raw key is derived from the keyboard location of the ANSI representation 
of the X raw key.

When I have the time again (not this week, I'm afraid), I'll have a look 
again.

                Shachar

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