I'm sorry for being reduced to newbe levels all over again, but there are quite some things I don't understand about the way X handles the keyboard mappings. I am using kxkb, which provides a KDE applet for real time switching of keyboards. Looking at /etc/X11/xkb/symbols/hebrew told me nothing I didn't know from looking at the key caps on my keyboard (I'm not near my computer, I'll attach them later).

Thing I am trying to say is that all my configuration came from a vanilla KDE Debian installation, Hebrew keyboard included. I don't know where KDE takes the keyboards from.

The reason I gave up on researching this on my own was the "Q" and "W" keys. In the Israeli keyboard, unshifted these keys issue the / and ' symbols respectively. These keys were not matched either (and pressing them convincingly issued these chars, so I know this is not a misunderstanding).

Dmitry Timoshkov wrote:

"Shachar Shemesh" [email protected] wrote:

...

I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL).

Please provide them for reference. I would suggest create new keyboard layouts using existing tables at /etc/X11/xkb/symbols/ though.

Ok, here is where I ask really dumb questions. How do I do that?

...

I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task:

I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected.

I guess that you should create 4 characters per key layout.

Why? I don't know what the AltGr and shift-AltGr keys stand for, but they are defenitely not used in an Israeli keyboard (nor, I noticed, almost any other european keyboard).

[skipped]

...

3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message.

It can be easyly added to the MappingNotify event handler.

Do you want to take ownership of the bug then? ;-)

I did notice that Windows sends the new language with that message, and does so in a different format than the codepage used by the keyboard layout struct (how many codepages ARE there for any given language, anyways?). There is also the matter of language, not covered by the keyboard layout at all.

Shachar

Dmitry Timoshkov wrote:

"Shachar Shemesh" [email protected] wrote:

...

The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9.

According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa What says xev when you type hebrew characters?

xev agrees with keysymdef.h. Strange......

I got the 0x0fxx codes by placing debug messages in the relevant places in keyboard.c. It seemed to me that keyboard.c received characters in the range 0x0fxx, but I just rechecked and it was 0x0cxx range again. Wwwwierd.

I am also having trouble editing keyboard.c with snavigator. Upon saving, it totally screws up the non-ASCII characters in the keyboard layouts. It didn't used to do that (I played with the default charset, and wound up on ASCII at the end), but what do the list have to say about converting the whole string to \x notation? Your native keyboard will be less readable on your personal machine, but the file will stand a lot less chances of corruption. Besides, there is no being in the world for which keyboard.c today shows all characters correctly anyways.

I am attaching a diff against the latest CVS (i.e. - overriding my previous patch) that does this, as well as a small C prog I used to generate this (it contains a very useful C state machine that understands comments and strings, and only replaces the files inside strings).

Oh oh, so this is not that simple. It appears that C will not terminate the \ processing, so '\x000000020' is a perfectly legal way of specifying space. As a result, we are having problems with some of the encodings being continued to the characters after the encoding. So, if the orginal string said: "F8E", after encoding that will be "\xf8E", and the compiler will try to understand it as one character. I checked, and it is defined like that in "The C programming language". We can translate it to "\xf8""E", but the resault will be way ugly.

I'm at a loss. Anyone cares to share their insight?

...

The second problem I encountered was that keymaps that had three letters per key, but the third letter was wrong, received the same score (i.e. - were not counted as mismatches) as keymaps that only had two letters. In fact, if the X representation had only two letters, the three letter keymaps were not penalized for trying to match a non-existing key. I believe this is not the right behaviour, but as it does not block me at the moment, I did not try to fix it.

Probably keyboard detection code need some additional work. But since it works for (almost?) all, then it's fine to leave it as it is.

Your'e right. I lack the incentive now too.

Shachar

/* * This is a small C state machine skeleton that can be used as a way to know whether your'e inside a string * or a comment when analyzing source. This code will fail miserably given creative preprocessor usage. * * This source code is copyrighted by Shachar Shemesh, and can be distributed freely under the GPL version 2 * license. You may, at your descression, use any later version of the GPL as the license. A copy of the * license can be obtained at http://www.fsf.org/licenses/gpl.txt */

#include <stdio.h>

int main() { int chr=0; enum state { PLAIN, SLASH, LCOMMENT, COMMENT, COM_STAR, DQUOTE, DQUOTE_BACKSLASH, QUOTE, QUOTE_BACKSLASH } state=PLAIN;

while( (chr=getchar())!=EOF ) { switch( state ) { case PLAIN: switch( chr ) { case '/': state=SLASH; break; case ''': state=QUOTE; break; case '"': state=DQUOTE; break; } break; case SLASH: switch( chr ) { case '/': state=LCOMMENT; break; case '*': state=COMMENT; break; default: state=PLAIN; break; } break; case LCOMMENT: switch( chr ) { case '\n': state=PLAIN; break; } break; case COMMENT: switch( chr ) { case '*': state=COM_STAR; break; } break; case COM_STAR: switch( chr ) { case '/': state=PLAIN; break; case '*': break; default: state=COMMENT; break; } break; case DQUOTE: switch( chr ) { case '"': state=PLAIN; break; case '\': state=DQUOTE_BACKSLASH; break; } break; case DQUOTE_BACKSLASH: state=DQUOTE; break; case QUOTE: switch( chr ) { case ''': state=PLAIN; break; case '\': state=QUOTE_BACKSLASH; break; } break; case QUOTE_BACKSLASH: state=QUOTE; break; }

if( chr>=0x80 && ( state==QUOTE || state==DQUOTE ) ) printf("\x%02X", chr ); else putchar(chr); }

return 0; }

Hi all,

Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention.

And I tried your patch Shachar and there some interesting results...

Here is my setxkbmap line to change between hebrew and english: setxkbmap -option grp:switch,grp:shift_toggle,grp_led:scroll il

This lets me switch from english to hebrew...

Then I tried the wine's internal wine's notepad to do a test: LANG=he_IL wine notepad at first the keyboard switch doesn't behave well (you got capital english letters and only after few times you get hebrew) I can type hebrew no problem all..

However, with programs like Word, excel etc.. - the problem persists - keyboard switching doesn't impress the application and even when you switch - you're in english mode...

Have you tried some apps with this? if so, which ones?

Thanks, Hetz

"Shachar Shemesh" [email protected] wrote:

Also, I believe that this patch is mostly about correctly matching the returned character (in ISO-8859-8, in my patch's case) with the scan code Windows programs expect under such situations. As such, it has mostly to do with games and such.

No, your patch helps not only to games. First of all all keyboard layouts contain code page value and correct code page plays great role when keyboard messages get translated to characters. And having correct keyboard layout selected (actually detected) is the very first step in having correct national keyboard layouts to work.

On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh [email protected] wrote:

I believe the problems you are experiencing have nothing to do with the keyboard layout problem, but with the keyboard switching detection.

Does it mean it should work if I change keyboard layout to non English and then launch Word?

I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)

BTW, how to do that (add myself as CC)?

Regards, Nerijus

On Sun, 02 Jun 2002 10:40:37 +0300 Shachar Shemesh [email protected] wrote:

...

Does it mean it should work if I change keyboard layout to non English and then launch Word?

What language are we talking about? If we are talking about a BiDi

It's Lithuanian.

Office (Hebrew or Arabic), I am not sure how Word will display the direction indicator. Like I told Hetz, I am pretty early in the process. I'm currently at the Text output functions, and things like "Word" are a bit in the future for me.

I don't know how and if Word needs to know about non-BiDi languages.

...

...

I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)

BTW, how to do that (add myself as CC)?

follow the link, and add your email address under the "add CC:" field (top right).

Oh, it was veeery right in Konqueror, now I see.

Regards, Nerijus