Re: slovene keyboard without dead keys

[Dmitry Timoshkov]

"Rok Mandeljc"  wrote:
> I have problems with XFree86 4.3 and wine's keyboard layout detection
> scheme. It seems that wine can't detect dead keys and use alt, therefore my
> previous slovene layout isn't detected anymore. This one loads perfectly,
> although alt-key combinations don't work.

I'm strongly against fixing problems with new XFree86 4.3.0 this way and
polluting x11drv with lots of similar keyboard layouts. A way to solve
your problem is to use something like this in your XF86Config:

Option "XkbLayout" "us,si"
Option "XkbOptions" "grp:ctrl_shift_toggle"

I.e. explicitly add "us" layout as the first language group and use
Ctrl+Shift to switch between base and alternate keyboard layouts.

slovene keyboard without dead keys

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> I'm strongly against fixing problems with new XFree86 4.3.0 this way and
> polluting x11drv with lots of similar keyboard layouts. A way to solve
> your problem is to use something like this in your XF86Config:
>
> Option "XkbLayout" "us,si"
> Option "XkbOptions" "grp:ctrl_shift_toggle"
>
> I.e. explicitly add "us" layout as the first language group and use
> Ctrl+Shift to switch between base and alternate keyboard layouts.

At some point we will have no choice but to add support in Wine to this. 
I am not a major hurt party, as my layout is going to be us,il even 
without the Wine problem, but this is causing people grief. This gets 
worse through the fact that the new X behaviour is actually a better 
one. We are now officially holding people back from moving a behaviour 
that is better for them.

I would volunteer to do it, except I'm unusually busy of late. I know 
that you have messed around with the keyboard code at some time. If you 
have time, I recommend you look at it. If not, I'll try to handle this 
as soon as I:
1. Get some time for Wine (I estimate at least a month - I'm actually 
managing to make business :-)
2. Finish the font dialog rewrite I'm in the middle of.

Shachar

slovene keyboard without dead keys

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> At some point we will have no choice but to add support in Wine to this. 
> I am not a major hurt party, as my layout is going to be us,il even 
> without the Wine problem, but this is causing people grief. This gets 
> worse through the fact that the new X behaviour is actually a better 
> one. We are now officially holding people back from moving a behaviour 
> that is better for them.

I don't see why explicitly adding a "us" keyboard layout would hurt people,
since before 4.3.0 release en_US was a mandatory layout existing whether
the user wanted it or not.
> I would volunteer to do it, except I'm unusually busy of late. I know 
> that you have messed around with the keyboard code at some time. If you 
> have time, I recommend you look at it.

Actually I have a plan to implement support for keyboard layout Win32 APIs
and that anyway requires rewrite of big chunks of the existing keyboard code
in x11drv, and as a part of that rewrite I'm going to decouple all existing
keyboard layout tables with a US English one and build new tables with LCID
and a layout id, but so far I don't know how to support several layouts for
single locale but with different code pages (for instance for Russian locale
we need to support 20866 (KOI8-R) and 1251 code pages).

slovene keyboard without dead keys

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> I don't see why explicitly adding a "us" keyboard layout would hurt people,
> since before 4.3.0 release en_US was a mandatory layout existing whether
> the user wanted it or not.

Ok, how about this. A Russian immegrant to Israel (and there are lots of 
those), would want his keyboard settings to be "us,il,ru". Windows 
supports this. X now supports this. Why shouldn't Wine?
> > I would volunteer to do it, except I'm unusually busy of late. I know 
> > that you have messed around with the keyboard code at some time. If you 
> > have time, I recommend you look at it.
>
> Actually I have a plan to implement support for keyboard layout Win32 APIs
> and that anyway requires rewrite of big chunks of the existing keyboard code
> in x11drv, and as a part of that rewrite I'm going to decouple all existing
> keyboard layout tables with a US English one and build new tables with LCID
> and a layout id,

Excellent. Please bear in mind, however, that sometimes it is 
desireable, and even crucial, to have more than one layout and switch. 
Also, the keyboard switching messages are crucial to some BiDi applications.

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.
> but so far I don't know how to support several layouts for
> single locale but with different code pages (for instance for Russian locale
> we need to support 20866 (KOI8-R) and 1251 code pages).

Don't they have different sub-langs? How does Win32 hadle this?

Shachar

slovene keyboard without dead keys

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> > I don't see why explicitly adding a "us" keyboard layout would hurt people,
> > since before 4.3.0 release en_US was a mandatory layout existing whether
> > the user wanted it or not.
>
> Ok, how about this. A Russian immegrant to Israel (and there are lots of 
> those), would want his keyboard settings to be "us,il,ru". Windows 
> supports this. X now supports this. Why shouldn't Wine?

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.
> > Actually I have a plan to implement support for keyboard layout Win32 APIs
> > and that anyway requires rewrite of big chunks of the existing keyboard code
> > in x11drv, and as a part of that rewrite I'm going to decouple all existing
> > keyboard layout tables with a US English one and build new tables with LCID
> > and a layout id,
>
> 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.
> Also, the keyboard switching messages are crucial to some BiDi applications.

Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages?
> 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. Also I don't know
whether XFree has a layout enumeration facility.
> > but so far I don't know how to support several layouts for
> > single locale but with different code pages (for instance for Russian locale
> > we need to support 20866 (KOI8-R) and 1251 code pages).
>
> Don't they have different sub-langs? How does Win32 hadle this?

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.

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

slovene keyboard without dead keys

[Dmitry Timoshkov]

"Shachar Shemesh"  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:
> - User presses key.
> - X sends virtual key to app (wine)
> - Wine translates virtual key to ascii.
> - Wine looks up the ascii in the currently selected keymap.
> - Wine translates ascii to virtual key
> - 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.
> - 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.
> - In particular - if the locale codepage is UTF-8, I cannot
> type any non-latin key, as the keyboard layouts are in ANSI
> codepages.
> - 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
> - 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.

slovene keyboard without dead keys

[Shachar Shemesh]

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

That's just INPUTLANGCHANGE, not the REQUEST. Let's hope it doesn't 
matter. I don't think many applications use this message to actually 
forbit a keyboard switch.
> > We use it today for comparing the keyboards.
>
> If you mean X11DRV_KEYBOARD_DetectLayout, then we don't.

Ok. I'l shut up until I collect further info.
> I'm afraid we can't change anything in that path.

Again. I'll do my homework and call in again.
> 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.

An improvement, and no doubt.
> 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.

We'll see how this problem resolves in X. It may just be that the X 
keyboard is going to have the keys pre-reveresed, and we can get away 
with simply defining a new keyboard and having is done with.

Shachar

slovene keyboard without dead keys

[Rok Mandeljc]

----- Original Message -----
From: "Dmitry Timoshkov" 
To: "Rok Mandeljc" 
Cc: 
Sent: Saturday, April 26, 2003 12:28 PM
Subject: Re: slovene keyboard without dead keys
> "Rok Mandeljc"  wrote:
> > I have problems with XFree86 4.3 and wine's keyboard layout detection
> > scheme. It seems that wine can't detect dead keys and use alt, therefore

my
> > previous slovene layout isn't detected anymore. This one loads

perfectly,
> > although alt-key combinations don't work.
>
> I'm strongly against fixing problems with new XFree86 4.3.0 this way and
> polluting x11drv with lots of similar keyboard layouts. A way to solve
> your problem is to use something like this in your XF86Config:
>
> Option "XkbLayout" "us,si"
> Option "XkbOptions" "grp:ctrl_shift_toggle"
>
> I.e. explicitly add "us" layout as the first language group and use
> Ctrl+Shift to switch between base and alternate keyboard layouts.
>
> --
> Dmitry.

Thanks for help, but that doesn't work for me. If I do Option "XkbLayout"
"us,si" my keyboard is properly detected, but dead keys (alt+something) are
screwed up both in wine and linux (in both us and si).

slovene keyboard without dead keys

[Dmitry Timoshkov]

"Rok Mandeljc"  wrote:
> Thanks for help, but that doesn't work for me. If I do Option "XkbLayout"
> "us,si" my keyboard is properly detected, but dead keys (alt+something) are
> screwed up both in wine and linux (in both us and si).

That's a completely different problem and very likely caused by missing proper
environment variables controlling locale needed by Wine.