Hi, On Tue, Sep 10, 2013 at 6:05 AM, Ken Thomases <k...@codeweavers.com> wrote: > Is there a specific problem that you're trying to fix?
Yes. I didn't file a bug report yet, but an application I am using (IBM Translation Manager) has some functionality bound to Ctrl-[0-9/] keypresses. Now with the Mac driver when I press Ctrl-1, for example, the function bound to Ctrl-1 is executed, but also '1' gets inserted into the active Richedit control which is wrong. > The Mac driver's ToUnicodeEx() implementation started out very similar to the > X11 driver's. It was basically a copy that I hacked on. It originally had > this same restriction. However, some testing revealed that this is not an > absolute restriction on Windows. For example, in the Khmer keyboard layout, > Control-<digit> produces characters for some digits. Given that some Windows > keyboard layouts produce characters for Control-<digit>, I figured it was > best left up to the Mac keyboard layout. > > Similarly for Control-<punctuation>. For example, the Windows Chinese > keyboard layouts produce characters for some of those keystrokes. So does > the Czech layout. Yes I investigated the Mac keyboard layout files and found out that the real problem is there - Ctrl-1 is really bound to produce '1' etc. But when I press Ctrl-1 e.g. in TextEdit nothing gets inserted and a "beep" is heard, but there is no simple way to understand what's happening due to TextEdit's closed-sourcedness. Thanks for the Khmer and Czech Windows layouts info. > It might still be possible to re-introduce this restriction if it can be > justified based on broad breakage of apps. Although even then, I'd want to > make it possible to override the restriction with a registry setting or > something. You never know if the ability to enter characters using these key > combinations might be crucial for certain Mac users because of the nature of > their native keyboard layout. I understand that this is rather a dirty hack, but after I found similar code in winex11.drv, I thought it might get through. > If a modification like this were justified, it should go earlier in > macdrv_ToUnicodeEx(). There's a section at the top where I moved the checks > for combinations that don't produce characters. > Also, the check should test that Alt is _not_ pressed, since > Control-Alt-<digit or punct> and Control-Alt-Shfit-<digit or punct> very > commonly produce characters. Control-Alt is a synonym for the AltGr key on > some keyboards (e.g. Swiss). > > Finally, if we're going to pursue this, there are some minor style issues I'd > prefer be changed. So, check with me before resubmitting. Ok, I'll retry, although after this answer of yours I have rather little hope left as I don't know any other apps affected by this behaviour, so it can't be called a 'broad' breakage. -- Ph.
