[GH-ISSUE #176] Сorrect display of shifted keys

gitea-mirror commented

2026-05-05 05:01:23 -06:00

Owner

Originally created by @becauseim on GitHub (Aug 6, 2020).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/176

Adobe Premiere Pro has standard keyboard shortcuts such as Shift+7, Shift+5, etc. On MacOS and WIN, these keyboard shortcuts produce different characters - as a result, I can't make a correct screencast. The viewer does not understand what key combinations are in action.

It would be correct if a number was replaced by characters only when typing, but not when calling shortcuts.

Will this be available in future updates?!

Originally created by @becauseim on GitHub (Aug 6, 2020). Original GitHub issue: https://github.com/keycastr/keycastr/issues/176 Adobe Premiere Pro has standard keyboard shortcuts such as Shift+7, Shift+5, etc. On MacOS and WIN, these keyboard shortcuts produce different characters - as a result, I can't make a correct screencast. The viewer does not understand what key combinations are in action. It would be correct if a number was replaced by characters only when typing, but not when calling shortcuts. Will this be available in future updates?! ![image](https://user-images.githubusercontent.com/23287366/89541958-b3bb7900-d807-11ea-8a87-52ffbb1c553e.png) ![image](https://user-images.githubusercontent.com/23287366/89541987-bc13b400-d807-11ea-91d2-9e3d6819fb93.png)

gitea-mirror closed this issue

2026-05-05 05:01:26 -06:00

gitea-mirror commented

2026-05-05 05:01:31 -06:00

Author

Owner

@bradydowling commented on GitHub (Aug 13, 2020):

Hopefully I'm not stepping on anyone's toes here but I don't think there's a scalable way for Keycastr to know what keybindings exist in other programs. So there's no way it could display a keypress conditionally if Premiere is open and has certain keybindings enabled.

The one solution I could think of for this would be to allow keycast override maps in preferences. Basically, this would allow you to specify certain strings to display for certain key combinations that are pressed. So in your case, when & would normally be displayed, it would reference the map and instead show the string that you have specified, which would be Shift + 7 or ⬆️ + 7 or whatever you want.

That being said, you'd likely have to implement this yourself because this seems pretty niche and it doesn't look like the maintainer(s) has much time to devote to this right now. Great app though.

So to answer your question, I'd say it's very unlikely you'll see an update with this feature in it.

@bradydowling commented on GitHub (Aug 13, 2020): Hopefully I'm not stepping on anyone's toes here but I don't think there's a scalable way for Keycastr to know what keybindings exist in other programs. So there's no way it could display a keypress conditionally if Premiere is open and has certain keybindings enabled. The one solution I could think of for this would be to allow keycast override maps in preferences. Basically, this would allow you to specify certain strings to display for certain key combinations that are pressed. So in your case, when `&` would normally be displayed, it would reference the map and instead show the string that you have specified, which would be `Shift + 7` or `⬆️ + 7` or whatever you want. That being said, you'd likely have to implement this yourself because this seems pretty niche and it doesn't look like the maintainer(s) has much time to devote to this right now. Great app though. So to answer your question, I'd say it's very unlikely you'll see an update with this feature in it.

gitea-mirror commented

2026-05-05 05:01:37 -06:00

Author

Owner

@becauseim commented on GitHub (Aug 13, 2020):

This is not about supporting a specific application, but about an obvious function: to display not the symbols that give keyboard shortcuts, but the keyboard shortcuts themselves.

Displaying symbols is relevant only when typing, and not when calling functions with a keyboard shortcut.

@becauseim commented on GitHub (Aug 13, 2020): This is not about supporting a specific application, but about an obvious function: to display not the symbols that give keyboard shortcuts, but the keyboard shortcuts themselves. Displaying symbols is relevant only when typing, and not when calling functions with a keyboard shortcut.

gitea-mirror commented

2026-05-05 05:01:40 -06:00

Author

Owner

@akitchen commented on GitHub (Aug 14, 2020):

@becauseim What you're referring to is more or less the same as what was brought up in https://github.com/keycastr/keycastr/issues/140 . ultimately we should consolidate and continue the conversation there.

@bradydowling is right, time to devote to this has been very limited lately, but this is one I have been looking into.

Unfortunately there are some limitations of what's possible here, I recall from having investigated quite some time ago. In your specific case, for shift-7, what comes through the event is literally & for both the event's characters and charactersIgnoringModifiers properties. What's interesting is that for cmd-shift-7 we receive 7 for characters and & for charactersIgnoringModifiers. In other words, the shift key is accounted for differently depending on whether other modifiers are used. And the layout of modified keys also differs across locales & keyboard layouts in ways we can't entirely predict.

We'd welcome any help or feedback from folks with locale and keyboard layout expertise on this one, but I doubt the raw shift-7 case is one we'd be able to support, at least not without a ton of special casing.

@akitchen commented on GitHub (Aug 14, 2020): @becauseim What you're referring to is more or less the same as what was brought up in https://github.com/keycastr/keycastr/issues/140 . ultimately we should consolidate and continue the conversation there. @bradydowling is right, time to devote to this has been very limited lately, but this is one I have been looking into. Unfortunately there are some limitations of what's possible here, I recall from having investigated quite some time ago. In your specific case, for `shift-7`, what comes through the event is literally `&` for both the event's `characters` and `charactersIgnoringModifiers` properties. What's interesting is that for `cmd-shift-7` we receive `7` for `characters` and `&` for ` charactersIgnoringModifiers`. In other words, the shift key is accounted for differently depending on whether other modifiers are used. And the layout of modified keys also differs across locales & keyboard layouts in ways we can't entirely predict. We'd welcome any help or feedback from folks with locale and keyboard layout expertise on this one, but I doubt the raw shift-7 case is one we'd be able to support, at least not without a ton of special casing.

gitea-mirror commented

2026-05-05 05:01:42 -06:00

Author

Owner

@akitchen commented on GitHub (Aug 14, 2020):

-> #140

@akitchen commented on GitHub (Aug 14, 2020): -> #140

gitea-mirror commented

2026-05-05 05:01:46 -06:00

Author

Owner

@akitchen commented on GitHub (Sep 2, 2020):

Is the problem stated in the original post specific to the number row? As far as I've been able to tell, those keycodes are stable across different keyboards and locales, and we probably could special-case them to make this happen

@akitchen commented on GitHub (Sep 2, 2020): Is the problem stated in the original post specific to the number row? As far as I've been able to tell, those keycodes are stable across different keyboards and locales, and we probably could special-case them to make this happen

gitea-mirror commented

2026-05-05 05:01:50 -06:00

Author

Owner

@akitchen commented on GitHub (Sep 2, 2020):

I guess I spoke too soon, there are indeed keyboard layouts which treat the "number row" differently, the obvious example being the French AZERTY layout . So this probably isn't something we're going to solve with special-casing. 🤔

@akitchen commented on GitHub (Sep 2, 2020): I guess I spoke too soon, there are indeed keyboard layouts which treat the "number row" differently, the obvious example being the French [AZERTY layout](https://en.wikipedia.org/wiki/AZERTY) . So this probably isn't something we're going to solve with special-casing. 🤔

gitea-mirror commented

2026-05-05 05:01:52 -06:00

Author

Owner

@becauseim commented on GitHub (Sep 9, 2020):

Okay, I realized that I do not need it all, but please make an option in the settings to display pressing combinations ⇧7 not like ".", But as "⇧7".

It's obviously that if I do not gain at the moment the text, and call a shortcut, you need to show not the character, but the very shortcut.

This option is not available for implementation? Why? The program can determine, I dialed the text at the moment, or just call the keyboard shortcut?

@becauseim commented on GitHub (Sep 9, 2020): Okay, I realized that I do not need it all, but please make an option in the settings to display pressing combinations **⇧7** not like **"."**, But as **"⇧7"**. It's obviously that if I do not gain at the moment the text, and call a shortcut, you need to show not the character, but the very shortcut. This option is not available for implementation? Why? The program can determine, I dialed the text at the moment, or just call the keyboard shortcut?

gitea-mirror commented

2026-05-05 05:01:53 -06:00

Author

Owner

@becauseim commented on GitHub (Sep 9, 2020):

Keycastr very visually pleasing and concise application, but it seems that it is created only for posts writers. At the moment I can not use it, the viewer does not understand maybe what key combination I pressed.

@becauseim commented on GitHub (Sep 9, 2020): Keycastr very visually pleasing and concise application, but it seems that it is created only for posts writers. At the moment I can not use it, the viewer does not understand maybe what key combination I pressed.

gitea-mirror commented

2026-05-05 05:01:56 -06:00

Author

Owner

@akitchen commented on GitHub (Sep 15, 2020):

So, ⇧7 is technically just & on a US keyboard layout. That's literally how it is represented in the internal CGEvent/NSEvent generated for each keystroke. It's only when control, option, or command are added to the keystroke that it's seen as a command key event with both the shifted and unshifted key provided in the event information.

Referring back to the original post, ⇧7 is not really a "shortcut", it is a keystroke which results in & being inputted via a keyboard event. I attempted to explain this in a previous comment.

I could foresee user-facing options for whether to prefer characters or charactersIgnoringModifiers, but it's more subtle and surprising than one might guess. I've been adding some unit tests on a branch which help illustrate the difference. Have a look at this test vs. this test to get a sense of what I mean.

When it comes to displaying ⇧7 as ⇧7 (on a US keyboard) I don't see a simple path forward without needing to implement a lookup of key codes to the current keyboard layout, which is a bit messy and arcane. If anyone wants to take a crack at implementing a lookup mechanism like this a pull request would be super welcome, even if partially incomplete, so long as the basic mechanism is there. See this SO post for more details.

@akitchen commented on GitHub (Sep 15, 2020): So, ⇧7 is technically just `&` on a US keyboard layout. That's literally how it is represented in the internal CGEvent/NSEvent generated for each keystroke. It's only when control, option, or command are added to the keystroke that it's seen as a command key event with both the shifted and unshifted key provided in the event information. Referring back to the original post, ⇧7 is not really a "shortcut", it is a keystroke which results in `&` being inputted via a keyboard event. I attempted to explain this in [a previous comment](https://github.com/keycastr/keycastr/issues/176#issuecomment-673775853). I could foresee user-facing options for whether to prefer `characters` or `charactersIgnoringModifiers`, but it's more subtle and surprising than one might guess. I've been adding some unit tests on a branch which help illustrate the difference. Have a look at [this test](https://github.com/keycastr/keycastr/blob/89f7d280644961bf58a81c42cfec2e9169f228fb/keycastr/KCVisualizerTests/KCVisualizerTests.m#L49) vs. [this test](https://github.com/keycastr/keycastr/blob/89f7d280644961bf58a81c42cfec2e9169f228fb/keycastr/KCVisualizerTests/KCVisualizerTests.m#L43) to get a sense of what I mean. When it comes to displaying ⇧7 as ⇧7 (on a US keyboard) I don't see a simple path forward without needing to implement a lookup of key codes to the current keyboard layout, which is a bit messy and arcane. If anyone wants to take a crack at implementing a lookup mechanism like this a pull request would be super welcome, even if partially incomplete, so long as the basic mechanism is there. See [this SO post](https://stackoverflow.com/questions/18408565/map-nsevent-keycode-to-virtual-key-code) for more details.

gitea-mirror commented

2026-05-05 05:01:58 -06:00

Author

Owner

@akitchen commented on GitHub (Jan 2, 2021):

See v0.9.9 for some improvements in this behavior

@akitchen commented on GitHub (Jan 2, 2021): See v0.9.9 for some improvements in this behavior

Rows
Columns

[GH-ISSUE #176] Сorrect display of shifted keys #149