winemac: Don't return characters for Ctrl-(non-letter symbol) keypresses from ToUnicodeEx() as X11 driver already does (try 2)

Phil Krylov phil at newstar.rinet.ru
Tue Sep 10 05:45:02 CDT 2013


Hi,

On Tue, Sep 10, 2013 at 6:05 AM, Ken Thomases <ken at 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.



More information about the wine-devel mailing list