Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@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:
- 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.
- 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
- 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.
- 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