slovene keyboard without dead keys

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>Yes, that's one of the cases when our current scheme doesn't work. But one
>excuse for us is that XFree86 4.3.0 is fairly new.
>  
>
All I was saying was that we NEED to support it. We can no longer hide 
behind X's inability to do so, as it now does. The new X keyboard 
layouts make much more sense, and making people effectively revert to 
the old one is an incorrect solution, IMHO.

>>Excellent. Please bear in mind, however, that sometimes it is 
>>desireable, and even crucial, to have more than one layout and switch.
>>    
>>
>
>That should be fairly easy to implement, since under XFree86 4.3 every international
>layout is not mixed with any other, even with an en_US one.
>  
>
I was meaning for X 4.3.0. I have no problem that people working with 
earlier versions will register under wine as having two keyboards (i.e. 
- US+another one).

>>Also, the keyboard switching messages are crucial to some BiDi applications.
>>    
>>
>Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages?
>  
>
That's what I mean.

>>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?

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

>Windows knows nothing about a KOI8-R based locale. 20866 is just one of
>the code page numbers. Of course in order to support it we may introduce
>new, Wine specific LCID with SUBLANG_RUSSIAN_KOI8R.
>  
>
We may have to.

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

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

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.

What I suggest (and what I was planning on doing myself, should I ever 
have any free time again) was to leave the current keyboard detection 
routine as is (seperating the different keyboards, of course), but not 
translate the VKey to ascii, but send it on as is.
When the application asks to translate, then we look it up in what we 
know to be the current keyboard. This way, if the keyboard layout has ( 
and ) non-switched, we will switch them ourselves. This means that Wine 
has a different keyboard than the rest of X, but that's on purpose.

                Shachar