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.


Reply via email to