NDHotKeyEvent fixes

[tiennou]

This imports NDHotKeyEvent as a submodule and fixes #1134 by listening for the correct notification.

See nathanday/ndhotkeyevent#2 for the NDHotKeyEvent diff, since it's now separate.

[pjrobertson]

Looks good and works fine for me.
I don't see any reason to wait for Nathan Day to merge your pull request on NDHotKeyEvent, but it may be worth it so it gets another look over.

Btw nice work on getting it all to work with 32/64 bit QS. I scratched my head for ages over it :(

[pjrobertson]

One small quirk I have found with this is that the ␣ character no longer displays.
Try setting your hotkey to ⌘␣ then look at it in the prefs.
Also, ⌘⎋ is getting grabbed as ⌘�A for some reason :/

[tiennou]

@pjrobertson: Better ? I won't be able to get more key recognized without access to a more complete keyboard (or someone who can get Key Codes) because I miss the kVK_ codes for things like Insert, Home, End, ...

[pjrobertson]

Haven't looked at the code (time for bed!)
…but you should be able to see a 'full' keyboard if you bring up the
keyboard viewer :)

On 14 November 2012 22:49, Etienne Samson [email protected] wrote:

@pjrobertson https://github.com/pjrobertson: Better ? I won't be able
to get more key recognized without access to a more complete keyboard (or
someone who can get Key Codes) because I miss the kVK_ codes for things
like Insert, Home, End, ...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1147#issuecomment-10389500.

[tiennou]

I didn't even think about it ;-). I spent some time yesterday scouring the Unicode Character palette to find symbols for those missing keys. But I just checked, the Keyboard Viewer has the same layout than my MacBook Pro, hence I'm still stuck...

[pjrobertson]

:(

OK, I'll post the key chars for all the extra keys now :)

On 15 November 2012 16:18, Etienne Samson [email protected] wrote:

I didn't even think about it ;-). I spent some time yesterday scouring
the Unicode Character palette to find symbols for those missing keys. But I
just checked, the Keyboard Viewer has the same layout than my MacBook Pro,
hence I'm still stuck...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1147#issuecomment-10414342.

[pjrobertson]

Here ya go:

Key Down
    Unicode:        63248 / 0xf710
    Keys:       F13
    Key Code:   105 / 0x69
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63249 / 0xf711
    Keys:       F14
    Key Code:   107 / 0x6b
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63250 / 0xf712
    Keys:       F15
    Key Code:   113 / 0x71
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63251 / 0xf713
    Keys:       F16
    Key Code:   106 / 0x6a
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63252 / 0xf714
    Keys:       F17
    Key Code:   64 / 0x40
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63253 / 0xf715
    Keys:       F18
    Key Code:   79 / 0x4f
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63254 / 0xf716
    Keys:       F19
    Key Code:   80 / 0x50
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63272 / 0xf728
    Keys:       ⌦
    Key Code:   117 / 0x75
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63273 / 0xf729
    Keys:       ↖
    Key Code:   115 / 0x73
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63275 / 0xf72b
    Keys:       ↘
    Key Code:   119 / 0x77
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63276 / 0xf72c
    Keys:       ⇞
    Key Code:   116 / 0x74
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        63277 / 0xf72d
    Keys:       ⇟
    Key Code:   121 / 0x79
    Modifiers:  8388864 / 0x800100

Key Down
    Unicode:        48 / 0x30
    Keys:       #0
    Key Code:   82 / 0x52
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        49 / 0x31
    Keys:       #1
    Key Code:   83 / 0x53
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        50 / 0x32
    Keys:       #2
    Key Code:   84 / 0x54
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        51 / 0x33
    Keys:       #3
    Key Code:   85 / 0x55
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        52 / 0x34
    Keys:       #4
    Key Code:   86 / 0x56
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        53 / 0x35
    Keys:       #5
    Key Code:   87 / 0x57
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        54 / 0x36
    Keys:       #6
    Key Code:   88 / 0x58
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        55 / 0x37
    Keys:       #7
    Key Code:   89 / 0x59
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        56 / 0x38
    Keys:       #8
    Key Code:   91 / 0x5b
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        57 / 0x39
    Keys:       #9
    Key Code:   92 / 0x5c
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        46 / 0x2e
    Keys:       .
    Key Code:   65 / 0x41
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        3 / 0x3
    Keys:       ⌅
    Key Code:   76 / 0x4c
    Modifiers:  256 / 0x100

Key Down
    Unicode:        43 / 0x2b
    Keys:       +
    Key Code:   69 / 0x45
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        45 / 0x2d
    Keys:       -
    Key Code:   78 / 0x4e
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        42 / 0x2a
    Keys:       *
    Key Code:   67 / 0x43
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        47 / 0x2f
    Keys:       /
    Key Code:   75 / 0x4b
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        61 / 0x3d
    Keys:       =
    Key Code:   81 / 0x51
    Modifiers:  2097408 / 0x200100

Key Down
    Unicode:        63289 / 0xf739
    Keys:       �the funny box with a cross through it. Top left of the num pad
    Key Code:   71 / 0x47
    Modifiers:  8388864 / 0x800100

[pjrobertson]

Btw just incase you still want to get key codes, and don't know about this:
http://manytricks.com/keycodes/

On 15 November 2012 16:21, Patrick Robertson [email protected]:

:(

OK, I'll post the key chars for all the extra keys now :)

On 15 November 2012 16:18, Etienne Samson [email protected]:

I didn't even think about it ;-). I spent some time yesterday scouring
the Unicode Character palette to find symbols for those missing keys. But I
just checked, the Keyboard Viewer has the same layout than my MacBook Pro,
hence I'm still stuck...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1147#issuecomment-10414342.

[pjrobertson]

@tiennou, any progress on this?

Having a clearing out day :)

[tiennou]

Rebased, hope you won't mind too much. I need that to investigate #1386 and #1482.

[tiennou]

Looks good to me, it fixes both issues above (#1386 because -[QSSearchObjectView handleBoundKey:] wouldn't have the correct theEventString, and #1482 because QSHotKeyEvent wouldn't have their updated key code).

@pjrobertson A 7 month-old pull request coming back to haunt us, I'd say ;-).

I'm not sure about the "display" keycode things. I fixed those I could, but either I still miss those keys on my keyboard (though I can now borrow my work one to test), or I can't find their NS*Key define.

[tiennou]

It seems to break command encapsulation... Investigating ;-).

[skurfer]

Rebased, hope you won't mind too much.

No, it's probably easier for everyone that way.

It seems to break command encapsulation... Investigating ;-).

OK, then I won't pull it yet.

[pjrobertson]

How's this looking @tiennou - did the investigating lead anywhere? ;-)
I think it's about time we had a pull req clean up so we can get the ARC ball rolling... :)

[tiennou]

It's hard. Using the newer NDHotKeyEvent stuff breaks shortcuts without 'characters' (a-zA-Z0-9) like Tab and Esc, but it fixes keyboard layout changes. Difference between our (old ?) version and the current one is that the latter NDHotKeyEvent class delegates keyboard layouts to (you've guessed it ;-)) NDKeyboardLayout and only keeps track of key "characters" (versus "keycodes").

There are two things I've tried :

• Add the missing keys to the UnmappedEntries. It fixes HotKeys problems, but break some bindings, those used by QSSearchObjectView in -handleBoundKey:, which impacts eg. command encapsulation. I looked closely at it, and it seems like objectForKey: fails while it should not, which prevent the corresponding selector to be called.
• Remove the missing keys (reverting some of my changes), and try to make it display correctly. I've traced it to somewhere where the code fails and drop the character information (the kVK_ESC code effectively becomes 0, and then this gets displayed as Q. But I don't remember where that was, somewhere along a call between KeyboardLayout and HotKey stuff :-S.

I don't really have time to take a closer look, sorry... If I find some time I will (it's pretty high in my priority list), but at the moment I'm pretty busy on realer life ;-).

[pjrobertson]

I'm pretty busy on realer life ;-).

Do you not use QS in the most real of real lives? ;-) hehe
No worries. Seems a bit over my head so it can wait until you have the time

Bonsoir

On 24 May 2013 00:44, Etienne Samson [email protected] wrote:

It's hard. Using the newer NDHotKeyEvent stuff breaks shortcuts without
'characters' (a-zA-Z0-9) like Tab and Esc, but it fixes keyboard layout
changes. Difference between our (old ?) version and the current one is that
the latter NDHotKeyEvent class delegates keyboard layouts to (you've
guessed it ;-)) NDKeyboardLayout and only keeps track of key "characters"
(versus "keycodes").

There are two things I've tried :

• Add the missing keys to the UnmappedEntries. It fixes HotKeys
  problems, but break some bindings, those used by QSSearchObjectView in
  -handleBoundKey:, which impacts eg. command encapsulation. I looked
  closely at it, and it seems like objectForKey: fails while it should
  not, which prevent the corresponding selector to be called.
• Remove the missing keys (reverting some of my changes), and try to
  make it display correctly. I've traced it to somewhere where the
  code fails and drop the character information (the kVK_ESC code
  effectively becomes 0, and then this gets displayed as Q. But I don't
  remember where that was, somewhere along a call between
  KeyboardLayout and HotKey stuff :-S.

I don't really have time to take a closer look, sorry... If I find some
time I will (it's pretty high in my priority list), but at the moment I'm
pretty busy on realer life ;-).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1147#issuecomment-18359685
.

[pjrobertson]

OK so turns out that my ramblings about fixing the keyboard stuff on the gGroups was unwarranted, since it's related to what @tiennou is already doing/done with 1f8b7d0be811ab33a5a84fb120db42d58fa38dcc

So... can we either just merge / cherry pick that one commit, or get this wrapped up (9 months already! :o)
If you need any help, let me know Etienne :)

[tiennou]

Sorry, I'm still time-constrained. And there's still the issue I explained above : either you get nice symbols for "silent" keys (Cmd, Ctrl, ...) but you loose most key bindings, or you get keybindings but triggers like Cmd-Esc display and work as Cmd-Q. The easiest way would be to fix the keybinding problem, but I couldn't understand why it didn't work in the first place...

[tiennou]

Gnnnhhhnn, I got it... This requires quicksilver/ndhotkeyevent#1 to be merged first so it's equivalent in functionality to what we have now.

Now I'm gonna wash myself in shame for not taking the time for such an easy fix ;-).

[tiennou]

This closes #1482 btw 🔥.

[pjrobertson]

No! Go wash yourself to get rid of that shame. No need! :)

P.S. I think fixing #1482 is going to annoy me ;-)
I'm currently using UK and Korean keyboards as my two most common layouts. When I switch to Korea, is this going to mean that all my triggers will die (since there are no latin chars on a Korean keyboard). At the moment I just happily use the same keys as always (i.e. the chars I can see on my keyboard) and everything works - since the trigger keys don't change.

[tiennou]

Yeah, I see what you mean, this keyboard layout stuff is hard to get right... I still have a radar filed for clarification of the difference between TISCopyCurrentKeyboardInputSource, TISCopyCurrentKeyboardLayoutInputSource, TISCopyCurrentASCIICapableKeyboardInputSource, and TISCopyCurrentASCIICapableKeyboardLayoutInputSource.

Anyways I don't think it will kill your triggers, just they won't respond anymore (unless something I don't expect happens — maybe a crash in NDKeyboardLayout because of the aforementioned Layout/non-Layout functions). Can you try running that one to see what happens (with a Triggers.plist backup handy of course) ?

[timvisher]

On Mon, Aug 19, 2013 at 7:24 PM, Patrick Robertson <[email protected]

wrote:

P.S. I think fixing #1482https://github.com/quicksilver/Quicksilver/issues/1482is going to annoy me ;-)

I'm currently using UK and Korean keyboards as my two most common layouts.
When I switch to Korea, is this going to mean that all my triggers will die
(since there are no latin chars on a Korean keyboard). At the moment I just
happily use the same keys as always (i.e. the chars I can see on my
keyboard) and everything works - since the trigger keys don't change.

This is interesting. For me, I switch between Qwerty and Dvorak at least
once or twice a day but when I'm in either of those modes I'm thinking in
terms of that keyboard which is why I've encountered this problem. It
sounds like you essentially hit triggers by pure muscle memory. If I
thought in those terms it might not be quite so much of an issue for me.

Another thing for me that would make it less annoying is if the key
re-mapping was consistent. The interesting bit, though, is that the key
remapping is not always consistent. See the end of this comment.
If I could always depend on the position, it'd be less of a big deal.

[pjrobertson]

It sounds like you essentially hit triggers by pure muscle memory.

I guess partly. But because the keyboard layouts other than QWERTY that I'm using don't have any of the same characters (this and this) there's no way for me to think in terms of keys ;-)
FYI what Apple does is leave the mappings alone (for these keyboard layouts at least - maybe Dvorak is different). So if I hit say ⌘ㅁ (ㅁ being the key where 'a' is on a Korean keyboard) I get the usual ⌘A - select all - shortcut. Same for ⌘V, ⌘X etc.

@tiennou, I'll take a look in the next day or so and report back :)

On 20 Awst 2013, at 23:08, Tim Visher [email protected] wrote:

On Mon, Aug 19, 2013 at 7:24 PM, Patrick Robertson <[email protected]

wrote:

P.S. I think fixing #1482https://github.com/quicksilver/Quicksilver/issues/1482is going to annoy me ;-)

I'm currently using UK and Korean keyboards as my two most common layouts.
When I switch to Korea, is this going to mean that all my triggers will die
(since there are no latin chars on a Korean keyboard). At the moment I just
happily use the same keys as always (i.e. the chars I can see on my
keyboard) and everything works - since the trigger keys don't change.

This is interesting. For me, I switch between Qwerty and Dvorak at least
once or twice a day but when I'm in either of those modes I'm thinking in
terms of that keyboard which is why I've encountered this problem. It
sounds like you essentially hit triggers by pure muscle memory. If I
thought in those terms it might not be quite so much of an issue for me.

Another thing for me that would make it less annoying is if the key
re-mapping was consistent. The interesting bit, though, is that the key
remapping is not always consistent. See the end of this comment.
If I could always depend on the position, it'd be less of a big deal.
—
Reply to this email directly or view it on GitHub.

[timvisher]

On Tue, Aug 20, 2013 at 10:44 AM, Patrick Robertson <
[email protected]> wrote:

It sounds like you essentially hit triggers by pure muscle memory.

I guess partly. But because the keyboard layouts other than QWERTY that
I'm using don't have any of the same characters (this and this) there's no
way for me to think in terms of keys ;-)
FYI what Apple does is leave the mappings alone (for these keyboard
layouts at least - maybe Dvorak is different). So if I hit say ⌘ㅁ (ㅁ being
the key where 'a' is on a Korean keyboard) I get the usual ⌘A - select all

• shortcut. Same for ⌘V, ⌘X etc.

For english keyboards it does seem to move the mappings. I haven't tried
with Colemak but at least with Dvorak all shortcuts move.

[pjrobertson]

Alright, so maybe we should do the same?
I'd hate for all my triggers to just disappear… (gimme a day so I can test and find out for sure though :D)

On 21 Awst 2013, at 00:08, Tim Visher [email protected] wrote:

On Tue, Aug 20, 2013 at 10:44 AM, Patrick Robertson <
[email protected]> wrote:

It sounds like you essentially hit triggers by pure muscle memory.

I guess partly. But because the keyboard layouts other than QWERTY that
I'm using don't have any of the same characters (this and this) there's no
way for me to think in terms of keys ;-)
FYI what Apple does is leave the mappings alone (for these keyboard
layouts at least - maybe Dvorak is different). So if I hit say ⌘ㅁ (ㅁ being
the key where 'a' is on a Korean keyboard) I get the usual ⌘A - select all

• shortcut. Same for ⌘V, ⌘X etc.

For english keyboards it does seem to move the mappings. I haven't tried
with Colemak but at least with Dvorak all shortcuts move.
—
Reply to this email directly or view it on GitHub.

[timvisher]

I would generally agree that for non-latin layouts the position of the
trigger should not change. For English keyboards I think they should. It's
simply a case of how I'm thinking about typing. Q exists in
Dvorak/Qwerty/Colemak. It doesn't in Kanji.

No idea how difficult that would be to implement though.

On Tue, Aug 20, 2013 at 11:21 AM, Patrick Robertson <
[email protected]> wrote:

Alright, so maybe we should do the same?
I'd hate for all my triggers to just disappear… (gimme a day so I can test
and find out for sure though :D)

On 21 Awst 2013, at 00:08, Tim Visher [email protected] wrote:

On Tue, Aug 20, 2013 at 10:44 AM, Patrick Robertson <
[email protected]> wrote:

It sounds like you essentially hit triggers by pure muscle memory.

I guess partly. But because the keyboard layouts other than QWERTY
that
I'm using don't have any of the same characters (this and this)
there's no
way for me to think in terms of keys ;-)
FYI what Apple does is leave the mappings alone (for these keyboard
layouts at least - maybe Dvorak is different). So if I hit say ⌘ㅁ (ㅁ
being
the key where 'a' is on a Korean keyboard) I get the usual ⌘A - select
all

• shortcut. Same for ⌘V, ⌘X etc.

For english keyboards it does seem to move the mappings. I haven't tried
with Colemak but at least with Dvorak all shortcuts move.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1147#issuecomment-22952787
.

[tiennou]

Ready to merge ! Unless @pjrobertson lost all its triggers ;-).

[pjrobertson]

Closing this in favour of #2594

There's probably more 'useful' stuff in this PR, but let's close this and fix any outlying issues separately.

Hi @tiennou :-)