Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assign a key code to events when “typing” text #1827

Merged
merged 4 commits into from May 1, 2014
Merged

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Apr 18, 2014

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 added 2 commits Apr 18, 2014
some applications only look at the key code and ignore the unicode value

fixes #1792
@skurfer
Copy link
Member Author

skurfer commented Apr 24, 2014

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
Copy link
Member

pjrobertson commented Apr 28, 2014

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

@@ -60,11 +60,19 @@ - (QSObject *)typeObject:(QSObject *)dObject {

- (void)typeString:(NSString *)string {
UniChar buffer;
CGKeyCode keyCode;
CGEventRef keyEvent = CGEventCreateKeyboardEvent(NULL, 0, true);
Copy link
Member

@pjrobertson pjrobertson Apr 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@skurfer skurfer Apr 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@pjrobertson pjrobertson Apr 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

tiennou commented Apr 28, 2014

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
Copy link
Member Author

skurfer commented Apr 28, 2014

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
Copy link
Member

tiennou commented Apr 28, 2014

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
Copy link
Member

pjrobertson commented Apr 28, 2014

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
Copy link
Member

pjrobertson commented May 1, 2014

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

pjrobertson added a commit that referenced this issue May 1, 2014
assign a key code to events when “typing” text
@pjrobertson pjrobertson merged commit dfcdf38 into master May 1, 2014
1 check passed
@pjrobertson pjrobertson deleted the i1792 branch May 1, 2014
@skurfer
Copy link
Member Author

skurfer commented May 1, 2014

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

Agreed. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants