Re: [Bug 10266] Numpad keyboard handling is strange, Del key produces two events
Perhaps we need to gather more input from other developers:
http://bugs.winehq.org/show_bug.cgi?id=10266
--- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2007-11-01 08:32:46 ---
But in that case, you will find all of your X11 applications on your desktop, including Firefox etc, confusing as well?
Yes, and this behaviour is very annoying and not consistent IMO.
Let's break down this statement into two: 1) "Not consistent" It might be interesting to compare with CapsLock. Shift can cancel CapsLock, but also substitute it. This is true on both Windows and Linux. Additionally, on Linux, NumLock works the same, ie Shift works in both directions. On Windows, however, Shift can only cancel NumLock, not substitute it. Regardless of whether users actually finds this useful or not, I think it's hard to argue for that this is "logical" or "consistent". 2) "Annoying" Can it be that you have a Windows background and are therefore used to the Windows behaviour? I haven't actually asked any users yet, but my general opinion is that all applications on the same desktop should behave the same, if possible. We are decorating the Windows windows with the normal window manager decorations etc so I think it's reasonable that the keyboard should behave according to the native system model. Another thing to keep in mind is that most users actually never use the numpad keys in conjunction with Shift. I know this from several years of experience of keyboard hacking - there have been plenty of bugs in many softwares in this area but very few actual bug reports.
Besides, I just tested with Wine's notepad and don't see the problem you are reporting.
Which keyboard layout are you using? On my system, Wine selects the Swedish keyboard layout. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
"Peter Åstrand" <astrand(a)cendio.se> wrote:
1) "Not consistent"
It might be interesting to compare with CapsLock. Shift can cancel CapsLock, but also substitute it. This is true on both Windows and Linux. Additionally, on Linux, NumLock works the same, ie Shift works in both directions. On Windows, however, Shift can only cancel NumLock, not substitute it. Regardless of whether users actually finds this useful or not, I think it's hard to argue for that this is "logical" or "consistent".
Current behaviour emulates what ToUnicodeEx does under Windows. And some apps depend on it.
2) "Annoying"
Can it be that you have a Windows background and are therefore used to the Windows behaviour?
When NumLock is off arrow kys on numpad should behave like normal arrow keys IMO. Perhaps you have an idea how to use keypad with NumLock turned off to move cursor, and to select text when needed with Shift just like arrow keys do?
Besides, I just tested with Wine's notepad and don't see the problem you are reporting.
Which keyboard layout are you using? On my system, Wine selects the Swedish keyboard layout.
I'm using us keyboard layout. -- Dmitry.
On Thu, 1 Nov 2007, Dmitry Timoshkov wrote:
Besides, I just tested with Wine's notepad and don't see the problem you are reporting.
Which keyboard layout are you using? On my system, Wine selects the Swedish keyboard layout.
I'm using us keyboard layout.
That explains it. I can confirm that this problem does not occur with the us layout, but with the sv layout. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
On Thu, 1 Nov 2007, Dmitry Timoshkov wrote:
1) "Not consistent"
It might be interesting to compare with CapsLock. Shift can cancel CapsLock, but also substitute it. This is true on both Windows and Linux. Additionally, on Linux, NumLock works the same, ie Shift works in both directions. On Windows, however, Shift can only cancel NumLock, not substitute it. Regardless of whether users actually finds this useful or not, I think it's hard to argue for that this is "logical" or "consistent".
Current behaviour emulates what ToUnicodeEx does under Windows. And some apps depend on it.
We shouldn't forget that the Wine keyboard implementation is a total mess. The code is full of special cases, makes wrong assumptions about the platform (such as relying on X11 keycodes, bug 1181), contains race conditions (bug 4923) and is, in general, very ugly. There are a lot of special cases. Some looks at the virtual key, others are a keysym, others at keycodes etc etc. The code is a mess. It's a good idea to try to have ToUnicodeEx work mainly as it does on Windows, but we are miles away from reaching this goal. At this point, just "make the stuff work as we want it with most applications" is a more realistic goal. When it comes to my actual patch, I'm not sure it actually changes the ToUnicodeEx behaviour. As far as I know, ToUnicodeEx returns zero characters for VK_LEFT etc, regardless of the shift state. What my patch is mainly change which vkey is generated, which should be safe.
Can it be that you have a Windows background and are therefore used to the Windows behaviour?
When NumLock is off arrow kys on numpad should behave like normal arrow keys IMO. Perhaps you have an idea how to use keypad with NumLock turned off to move cursor, and to select text when needed with Shift just like arrow keys do?
With the X11/QT model, this is not possible. You need to turn NumLock on to select text. This problem isn't just about "taste", it's a real compatibility problem. A typical way of generating a numpad dot in X11 is to press Shift+NumpadDel. This will typically generate the keysym XK_KP_Decimal. Or, in other layouts (such as Swedish), you will get XK_KP_Separator. In other words, the KeyPress event from the X server contains semantic information: "The user wants a keypad separator symbol". Translating this to "Mark the character to the left" is just plain wrong! One actual case when this is a problem is with VNC. When the VNC servers recieves a XK_KP_Separator keyboard event, it typically generates an event which contains the same XK_KP_Separator keysym. With most layouts, this means using Shift, since typical xmodmaps looks like: keycode XYZ = KP_Delete KP_Separator Again, it's vital that Wine translates this into a separator symbol, or there will be no way of generating such a symbol via VNC. Btw, I've asked a dozen of people what they think. Most are advanced users, using different kinds of platforms. The result is pretty interesting. None knew the effect of Shift+Numlock, and only 25% were finding the behaviour of Shift (without NumLock) logic. Even more interesting is that 5 users actually preferred a model which doesn't exist on neither Linux nor Windows: The case where NumLock+shift is the same as just NumLock. Most users said that they were never using Shift with numpad keys at all. Another interesting fact is that none expected or preferred the current Wine behaviour. I've updated my HOWTO with some new information, still available as http://www.cendio.com/~astrand/keyboards/numpad.txt. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
"Peter Åstrand" <astrand(a)cendio.se> wrote:
Current behaviour emulates what ToUnicodeEx does under Windows. And some apps depend on it.
We shouldn't forget that the Wine keyboard implementation is a total mess. The code is full of special cases, makes wrong assumptions about the platform (such as relying on X11 keycodes, bug 1181), contains race conditions (bug 4923) and is, in general, very ugly. There are a lot of special cases. Some looks at the virtual key, others are a keysym, others at keycodes etc etc. The code is a mess.
The patches are always welcome, especially if they add a test case for each fix.
It's a good idea to try to have ToUnicodeEx work mainly as it does on Windows, but we are miles away from reaching this goal.
What goal are you talking about? Since I'm very closely track all locale and keyboard input related problems current code works very well, including international keyboard input. The only feature that is missing is support for loadable keyboard layouts.
At this point, just "make the stuff work as we want it with most applications" is a more realistic goal.
And the stuff really works.
When it comes to my actual patch, I'm not sure it actually changes the ToUnicodeEx behaviour. As far as I know, ToUnicodeEx returns zero characters for VK_LEFT etc, regardless of the shift state.
What my patch is mainly change which vkey is generated, which should be safe.
If you have a test case that doesn't pass without your patch and passes with then your patch is acceptable, otherwise it's not.
Btw, I've asked a dozen of people what they think. Most are advanced users, using different kinds of platforms. The result is pretty interesting. None knew the effect of Shift+Numlock, and only 25% were finding the behaviour of Shift (without NumLock) logic. Even more interesting is that 5 users actually preferred a model which doesn't exist on neither Linux nor Windows: The case where NumLock+shift is the same as just NumLock. Most users said that they were never using Shift with numpad keys at all.
Another interesting fact is that none expected or preferred the current Wine behaviour.
It this case it doesn't really matter what users expect or prefer, behaviour of ToUnicodeEx is predefined by what Windows does. -- Dmitry.
On Fri, 2 Nov 2007, Dmitry Timoshkov wrote:
It's a good idea to try to have ToUnicodeEx work mainly as it does on Windows, but we are miles away from reaching this goal.
What goal are you talking about?
The goal of a implementation of ToUnicodeEx that is 100% compatible with Windows.
Since I'm very closely track all locale and keyboard input related problems current code works very well, including international keyboard input. The only feature that is missing is support
I disagree. Two examples: 1) Shift-Numlock-Del generating Backspace AND a comma, using the sv layout. 2) The race condition (bug 4923). We had to modify our Xserver to send keyboard events *slowly* to Wine, to avoid this. With these bugs still existing, I don't thinks reasonable to say that the implementation "works very well". There are several other bugs in the Bugzilla as well, as well as 22 FIXMEs in the source.
Another interesting fact is that none expected or preferred the current Wine behaviour.
It this case it doesn't really matter what users expect or prefer, behaviour of ToUnicodeEx is predefined by what Windows does.
You are missing the point. We can have a 100% Windows compatible ToUnicodeEx but still select the model we want. It's just about what input we should feed to ToUnicodeEx. EVENT_event_to_vkey isn't a Windows API, so we can modify it how we want. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
participants (2)
-
Dmitry Timoshkov -
Peter Åstrand