[Bug 10266] Numpad keyboard handling is strange, Del keyproducestwo events

Dmitry Timoshkov dmitry at codeweavers.com
Fri Nov 2 07:22:38 CDT 2007

"Peter Åstrand" <astrand at 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

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


More information about the wine-devel mailing list