Hi, I have a pretty good estimate of what needs to be done to get Word supported in Hebrew. The current problems have to do with Word calling "GetKeyboardLang" after each character, and using the result as a basis for interpreting each received character. Currently, this function just returns the system locale, which causes Word to assume each and every letter is a Hebrew one, even the English ones. The results are pretty catastrophic, as people have reported (typing "Hi there everyone" typically results in the screen showing "Hthere everyone i", with "yone" highlighted with green to say it has syntax correction to suggest. The correct is to replace "there" with "they're"). I have been itching to do an overhaul of the Wine keyboard handling for some time. I think the current scheme is overly complicated, and causes problems. This is a major task, but I may be able to recrute some local help. I am a bit worried, however, about the fact that some other people may also working on a similar task at the moment. I know Dmitry said in the past he is rennovating the keyboard a little, and I know codeweavers still hold a patch that will allow UTF-8 input locale to work. I would like to coordinate the effort. If anyone is working on the keyboard right now, please let me know. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I have been itching to do an overhaul of the Wine keyboard handling for some time. I think the current scheme is overly complicated, and causes problems. This is a major task, but I may be able to recrute some local help. I am a bit worried, however, about the fact that some other people may also working on a similar task at the moment. I know Dmitry said in the past he is rennovating the keyboard a little, and I know codeweavers still hold a patch that will allow UTF-8 input locale to work.
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. 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. 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. 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, and therefore make it possible to make international keyboard input work even if we have made a mistake while detecting an X keyboard layout. What exactly part of it you see could be simplified, and how? -- Dmitry.
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/
Hi all, I think I found what is needed in order to implement my suggested keyboard support. The only drawback is that it requires the use of XKB, which is not a given in all Xservers. Personally, I find it hard to believe that there are many X servers that don't support it (the extension is from 1997). Anyone has anything to say in terms of policy? Suggestions? Shachar Shachar Shemesh wrote:
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/
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
I think I found what is needed in order to implement my suggested keyboard support. The only drawback is that it requires the use of XKB, which is not a given in all Xservers. Personally, I find it hard to believe that there are many X servers that don't support it (the extension is from 1997).
Xvnc does not support the XKB extension. It may never do, as far as I understand the issue; it is not obvious how it should work anyway. On the other hand, you may not care... Good international keyboard support is probably worth it. Feri.
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I think I found what is needed in order to implement my suggested keyboard support. The only drawback is that it requires the use of XKB, which is not a given in all Xservers. Personally, I find it hard to believe that there are many X servers that don't support it (the extension is from 1997).
Anyone has anything to say in terms of policy? Suggestions?
AFAIK the policy always was: make it work first with some particular configuration, and improve the situation adding functionality for other platforms/configurations later on. -- Dmitry.
"Shachar Shemesh" <wine-devel(a)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.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)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/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I get "unknown key". I'll try to recompile with it and let you know.
If you have seen that message before, that's normal that it hasn't disappeared. The patch is not supposed to fix that kind of messages, it just should use code page associated with current locale to translate X keyboard events to unicode. That's all the patch is supposed to do. -- Dmitry.
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.
I tried it and it does NOT work. I still get "unrecognized keyboard event". Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
participants (4)
-
Dmitry Timoshkov -
Ferenc Wagner -
Shachar Shemesh -
Shachar Shemesh