[GH-ISSUE #187] Provide an option to display actual keycaps vs modified keys #159

New issue

Closed

opened 2026-05-05 05:02:24 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 05:02:24 -06:00

Owner

Originally created by @akitchen on GitHub (Jan 10, 2021).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/187

There are different cases when users want to broadcast the actual keycaps typed vs how they are resolved when typing. This comes up with shifted and option/alternate key combinations. The PTKeyCode framework bundled with ShortcutRecorder makes this easy enough to do, but it needs to be governed by a user-facing option. See #140 and others for more background.

This is best approached after the MainMenu nib is modernized and easier to work with. #186

Originally created by @akitchen on GitHub (Jan 10, 2021). Original GitHub issue: https://github.com/keycastr/keycastr/issues/187 There are different cases when users want to broadcast the actual keycaps typed vs how they are resolved when typing. This comes up with shifted and option/alternate key combinations. The PTKeyCode framework bundled with ShortcutRecorder makes this easy enough to do, but it needs to be governed by a user-facing option. See #140 and others for more background. This is best approached after the MainMenu nib is modernized and easier to work with. #186

gitea-mirror

2026-05-05 05:02:24 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:02:31 -06:00

Author

Owner

@alexrmann commented on GitHub (Feb 4, 2021):

I support this revision! There are also other ways to looks at this issue. Consider the following use cases:

I wish to see the shift key display, using the Default visualizer. This use case would be resolved by the proposed revision expressed here and previously expressed in #104 and #140.
I wish to see the shift key display, using the Svelte visualizer. This is currently possible, due to the illumination of the persistently visualized modifier keys, however a difference between the Default and Svelte visualizer is the persistent visualization of keystrokes and the bezel on screen. If I wanted to minimize visual pollution, I have to use the Default visualizer. If I don't mind the persistence of the Svelte visualizer, I now have to accept that my keystrokes won't be cleared until I use a modifier key. This use case should spur another issue ticket for providing an option to fade out key strokes while using the Svelte visualizer.

@alexrmann commented on GitHub (Feb 4, 2021): I support this revision! There are also other ways to looks at this issue. Consider the following use cases: 1. I wish to see the shift key display, using the Default visualizer. This use case would be resolved by the proposed revision expressed here and previously expressed in #104 and #140. 2. I wish to see the shift key display, using the Svelte visualizer. This is currently possible, due to the illumination of the persistently visualized modifier keys, however a difference between the Default and Svelte visualizer is the persistent visualization of keystrokes and the bezel on screen. If I wanted to minimize visual pollution, I have to use the Default visualizer. If I don't mind the persistence of the Svelte visualizer, I now have to accept that my keystrokes won't be cleared until I use a modifier key. This use case should spur another issue ticket for providing an option to fade out key strokes while using the Svelte visualizer.

gitea-mirror commented

2026-05-05 05:02:35 -06:00

Author

Owner

@akitchen commented on GitHub (Feb 11, 2021):

@afkaqualls Please try out v0.9.10 for the change in shift key behavior. This particular issue is now about making this change in behavior toggle-able

And feel free to open issues for improving the Svelte visualizer; it has been less of a focus.

@akitchen commented on GitHub (Feb 11, 2021): @afkaqualls Please try out v0.9.10 for the change in shift key behavior. This particular issue is now about making this change in behavior toggle-able And feel free to open issues for improving the Svelte visualizer; it has been less of a focus.

gitea-mirror commented

2026-05-05 05:02:39 -06:00

Author

Owner

@marcotrosi commented on GitHub (Nov 4, 2023):

didn't want to open a new issue, this here seems close enough

I have the issue that I need to display the final character my OS would write.
for example when I press Alt-u then I don't want to see Alt-u, I want to see what Alt-u produces, in my case opening square bracket [, because I have a custom keyboard layout, otherwise it would be ¨ by default on macOS with German layout.

So it would be great if there was an option that shows the final translated character based on the current keyboard layout selected.

Same for Upper case characters. When I press Shift-u then I want to see only U and not Shift-u or Shift-U.

Such configuration would be useful for me because in my Vim screencasts it doesn't matter which keys you pressed, it only matters which characters are behind. So in my example above, [ has meaning because it's a command in that tool I use, and nobody would understand the keys pressed.
I hope I was able to explain the problem. Please reach out in case it's not clear.
Have a great day.

@marcotrosi commented on GitHub (Nov 4, 2023): didn't want to open a new issue, this here seems close enough I have the issue that I need to display the final character my OS would write. for example when I press `Alt-u` then I don't want to see `Alt-u`, I want to see what `Alt-u` produces, in my case opening square bracket `[`, because I have a custom keyboard layout, otherwise it would be `¨` by default on macOS with German layout. So it would be great if there was an option that shows the final translated character based on the current keyboard layout selected. Same for Upper case characters. When I press `Shift-u` then I want to see only `U` and not `Shift-u` or `Shift-U`. Such configuration would be useful for me because in my Vim screencasts it doesn't matter which keys you pressed, it only matters which characters are behind. So in my example above, `[` has meaning because it's a command in that tool I use, and nobody would understand the keys pressed. I hope I was able to explain the problem. Please reach out in case it's not clear. Have a great day.

gitea-mirror commented

2026-05-05 05:02:41 -06:00

Author

Owner

@akitchen commented on GitHub (Aug 25, 2024):

https://github.com/keycastr/keycastr/releases/tag/v0.10.0

@akitchen commented on GitHub (Aug 25, 2024): https://github.com/keycastr/keycastr/releases/tag/v0.10.0