assign a key code to events when “typing” text

[skurfer]

Thanks to CoRD being open source, I was able to run it in a debugger and examine the keyboard behavior, which gave me some ideas that led to the answer. The answer, by the way, is right there in the comments for CGEventKeyboardSetUnicodeString():

Note that application frameworks may ignore the Unicode string in a keyboard event and do their own translation based on the virtual keycode and perceived event state.

Remote Desktop clients apparently fall into this category.

I notice that we’re only sending key down events, but never sending the corresponding up event. It seems to work anyway, but should we fix that?

Also note that Type Text still mangles certain characters in Unicode-string-ignoring apps, but that was probably always the case. I can live with it.

[skurfer]

I found another place where the issue can be reproduced. If you have XQuartz installed and use Type Text in xterm, you can see the problem. This also helped me answer my own question about key up events.

One remaining problem is that characters that require modifiers are still wrong. For example, http://foo ⇥ Type Text gives you “httpa//foo”. Any ideas on that one?

[pjrobertson]

I found another place where the issue can be reproduced. If you have XQuartz installed and use Type Text in xterm, you can see the problem

Nice, I can reproduce, and can see your fix

This also helped me answer my own question about key up events.

That was probably just overlooked, yes, they should always be sent

I've tried and tried to get things like the : character to type correctly, but I can't find a way. I'm not sure of the fix. I think we may just have to roll with it, unless @tiennou's NDKeyboard fixes (which are still waiting to be merged would fix it, but I don't think so

[pjrobertson]

What's the point in creating an even here that's never used?
Why not just CGEventRef keyEvent = NULL

[skurfer]

I got that from you. 😃 I figured there was a reason, but I’ll take it out and make sure nothing breaks.

[pjrobertson]

Hehe. Oops :P
That comment was meant to errr... try and catch you out? FWIW I did a quick test without it and it seemed to work fine

(Is this something we should write a unit test for, since there are lots of edge cases? If not, maybe we should at least put in the comments to the methods things like:

• Xterm is dodgy, as is RemoteDesktop
• Some apps only work with key codes and not the unicode string
• etc.
  )

[tiennou]

For the record, here are my results (running vanilla 400A) :

• Using http://foo => Type Text against Terminal works here — so @pjrobertson is right, it's related to a missing ⇧ modifier (FR keyboard layout has a direct : key, and IIRC US doesn't).
• The same against XQuartz's xterm yields an infinite pasting of ssssss, and pressing modifiers change it "in some way", but the typing never stops (at least until switched from, or ⌃C).

I'll try to give a spin to it tonight, as well as checking it against my NDKeyboard branch. But again, I don't remember a way of reconstructing a "keycode sequence" from a given string in NDKeyboard( though it might be doable).

[skurfer]

Using http://foo => Type Text against Terminal works here — so @pjrobertson is right, it's related to a missing ⇧ modifier (FR keyboard layout has a direct : key, and IIRC US doesn't).

Actually, it works in most apps (even with a US keyboard) because they seem to use the key event’s unicode string instead of its key code. We only see problems in places that rely on the key code (XQuartz and MS Remote Desktop).

The same against XQuartz's xterm yields an infinite pasting of ssssss, and pressing modifiers change it "in some way", but the typing never stops (at least until switched from, or ⌃C).

That was fixed (on this branch) by supplying a key code and sending the corresponding key up events, but that only works for things that can be typed without modifiers.

[tiennou]

We only see problems in places that rely on the key code (XQuartz and MS Remote Desktop).

Does trying to CGEventPost to somewhere else than kCGHIDEventTap makes a difference for the remote/xterm case (I'm asking because the description of kCGSessionEventTap looks promising) ?

that only works for things that can be typed without modifiers.

Ok, I'll try to see if there's a way to extend NDKeyboard to handle that for us.

[pjrobertson]

Does trying to CGEventPost to somewhere else than kCGHIDEventTap makes a difference for the remote/xterm case (I'm asking because the description of kCGSessionEventTap looks promising) ?

No. I tried that, and all other combinations. Still a problem. For the record, I tried:

• Using a key code of 0
• Hard coding UniChar c = ‘:’; (as a quick test)
• Using kCGSessionEventTap instead of kCGHIDEventTap
• No key up
• Using no key code and only CGEventKeyboardSetUnicodeString
• Vice versa - using only a key code and no CGEventKeyboardSetUnicodeString
• Reloading the NDKeyboardLayout mappings (-[NDKeyboardLayout generateMappings])

Nothing worked for the one case of typing ‘:’ into Xterm. It always gave me ‘a’.
As Rob said, the ‘sssssss’ problem is fixed by this pull.

On 28 Ebrill 2014, at 20:11, Etienne Samson notifications@github.com wrote:

Does trying to CGEventPost to somewhere else than kCGHIDEventTap makes a difference for the remote/xterm case (I'm asking because the description of kCGSessionEventTap looks promising) ?

[pjrobertson]

Since I think this is an uncommon edge case, and it was broken anyway (and we need to get that stupid v1.2 release out!), I'm going to merge this.

We should keep #1792 open to remind us of the : → a bug

[skurfer]

We should keep #1792 open to remind us of the : → a bug

Agreed. Thanks.