slovene keyboard without dead keys

Dmitry Timoshkov dmitry at baikal.ru
Mon Apr 28 19:28:44 CDT 2003


"Shachar Shemesh" <wine-devel at shemesh.biz> wrote:

> >>Also important is an ability by the system to change keyboards. One such 
> >>requirement is for BiDi text editing, where the algorithm includes, 
> >>among other things, instances where it is necessary to change the 
> >>current keyboard layout.
> >>    
> >>
> >I'm not sure XFree86 supports this feature. Without support from X we couldn't
> >implement keyboard layout changes on application request.
> >
> Can't you set the current group? How are you planning on implementing 
> "INPUTLANGCHANGEREQUEST" otherwise?

Just reflect the change on the X notification event and inform the app about it.

> > Also I don't know
> >whether XFree has a layout enumeration facility.
> >  
> >
> We use it today for comparing the keyboards.

If you mean X11DRV_KEYBOARD_DetectLayout, then we don't.

> I feel really bad about this, especially as I cannot perform any useful 
> task myself at the moment, but there is one more question. Can we 
> shorten the current path each key takes?
> Current path:
> 
>    1. User presses key.
>    2. X sends virtual key to app (wine)
>    3. Wine translates virtual key to ascii.
>    4. Wine looks up the ascii in the currently selected keymap.
>    5. Wine translates ascii to virtual key
>    6. Virtual key is sent to Windows application, which translates it
>       back to ascii (usually).

I'm afraid we can't change anything in that path.

> This is broken on two very hurting points.
> 
>    1. If the current locale doesn't allow for the ascii for the key
>       pressed, it will not pass on to the application, even if the app
>       is a UNICODE app.
>          1. In particular - if the locale codepage is UTF-8, I cannot
>             type any non-latin key, as the keyboard layouts are in ANSI
>             codepages.
>    2. There is no chance in hell in supporting a English+Hebrew+Russian
>       application, as the last two languages use two distinct codepages,
>       which cannot, technically, be loaded simultaniously (see 1.1 above
>       for why UTF-8 will not work).

There is a patch in CX Office which supports UTF-8 encoded keyboard input
(in the case of UTF-8 locale of X Input Method) and makes it possible to avoid
conversion to current locale code page and back to unicode. If Alexandre considers
it clean enough he will certainly merge it into WineHQ tree.

> Last, there is a problem that does not hurt so much, but is still a problem
> 
>    3. There is great uncertanty regarding the matter of whose
>       responsibility it is to mirror characters on right to left
>       language keyboards. Mirroring is the process of emiting "(" when
>       shift-0 is pressed, despite it being the character opposite the
>       one engravd on the keyboard, and trusting the BiDi display to
>       mirror it back. Some say the X keyboard layout should do it, while
>       others say the infrastructure should do it.

I'm not an expert on right-to-left layouts and can't comment on this. If you
(or somebody else) feel to be a motivated enough to learn how it supposed to
work under real Windows and implement this behaviour in Wine taking into account
X peculiarities that would be great.

-- 
Dmitry.





More information about the wine-devel mailing list