Fsnotes: Keyboard shortcuts, Dvorak issue

[ghost]

Similar to issue #124, which unfortunately I did not see before creating this. (Sorry!) I use the Dvorak keyboard layout instead of Qwerty. There are differences in the arrangement of the letters. So in Dvorak, the "B" key is where the "N" key is in Qwerty. FS Notes is reading my _Command + B_ keystroke as the shortcut to create a new note.

[jeff-h]

Interesting! I've never used alternate keyboard layouts but have just set it up so I can play with it. I'll try to have a poke at this tonight.

[jeff-h]

Wow, this is nasty. There's a lot of sample code out there that is plain wrong if anyone is ever going to use a keyboard layout different than ANSI.

@glushchenko — hoping my research might be useful to you... this is going to be a pretty deep change, I fear, so I'm hoping you'll be happy to tackle it.

We currently use event.keyCode throughout the code, to obtain the int for the character that the user pressed. On my keyboard, b is 11 for example.

However, event.keyCode returns an int which actually refers to a key's position on the keyboard, regardless of which keyboard layout is in use. There is no guarantee what character is printed on that key. Dvorak (and any other non-ANSI keyboard layout) may or may not have b at the key in position 11. Dvorak for example has n on key 11.

Thus, we should not be using event.keyCode to detect the character pressed — I guess we shouldn't be using it anywhere at all. The recommendation here suggests using event.characters, which seems reasonably easy to retrofit, although the pluralisation of that method makes me uneasy — I'm not sure how you can arrive there with multiple characters in the string.

My main concern, and the reason I didn't go ahead and do this, is that I don't feel I have a good understanding of your implementation of the shortcut detection, how that interacts with the menu system, a few of the magic numbers still in the code (eg event.modifierFlags.rawValue == 393475) etc nor the possible implications of this change across the various filetypes you support (plain, RTF, markdown).

[gingerbeardman]

This seems familiar. I remember VSCode having a similar issue a while ago. So this analysis may be useful: https://github.com/Microsoft/vscode/issues/17521

Aside: I'd guess the magic numbers could be decimal representations of binary bitmasks?

[jeff-h]

I should clarify my comment above — by "deep" I actually mean "shallow" but wide hehehe There are a whole lot of places that will need to be converted across, but none of it is especially complex (says me who's not volunteering to make the changes!).

@gingerbeardman Thanks — I'll check that out.

[gingerbeardman]

Also: https://stackoverflow.com/questions/3202629/where-can-i-find-a-list-of-mac-virtual-key-codes/16125341

I'm going to look into this more.

[Dirklectisch]

Even the most basic shortcuts like command-c for copying text don't work using the Dvorak layout. Much appreciated if someone could get this fixed (I haven't written any Swift myself).

[Dirklectisch]

The latest patch fixed keyboard shortcuts using Dvorak for me. Thanks @glushchenko !

[jonbash]

This continues to be an issue for me; I'm on the latest version from the macOS App Store (3.3.5). Lots of keyboard shortcuts are not working correctly.

[matt99991]

I'm seeing this too with cmd+v in the Dvorak layout not actually pasting text into a note but instead putting the pasted text into the search box. It also occurs when using a text expander to expand a text snippet within a note.

[glushchenko]

Thanks guys, I will try to fix that in next release

[glushchenko]

Shortcut ⌘ - . and ⌘ - v fixed. Anything else?

[matt99991]

Those are the ones that I noticed. Thank you for fixing this! I'll take a look at the updated release