On Thu, 1 Nov 2007, Dmitry Timoshkov wrote:
- "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