mirror of
https://github.com/keycastr/keycastr.git
synced 2026-05-15 14:15:50 -06:00
[GH-ISSUE #140] Key combinations involving 'shift' should display the glyph for the original key pressed, not the shifted/modified result #115
Labels
No labels
bug
compatibility
discussion
documentation
enhancement
help wanted
help wanted
investigation needed
pull-request
release
visualizer
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/keycastr#115
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @akitchen on GitHub (May 10, 2019).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/140
When I type cmd-shift-1, I should see ⇧⌘1, not ⇧⌘! - this is how it is commonly displayed in macOS application menus.
@toootone commented on GitHub (Nov 26, 2019):
Maybe a checkbox in the settings for displaying "menu style" keypresses - something like "overlay shows unmodified key labels only". For example, the selection tool in Adobe products is the "V" key. The screen overlay would look a little better displayed as V rather than v. Likewise with other keys. This mode should also accomplish the original issue posted by @akitchen - key combinations involving shift would then simply display the main key label rather than the modified shifted character. For letters this would be capitals such as "A" since that is the label on the key, for numbers and punctuation, it would be 123 ,./ and not !@#<>? I recently used a key combination in a screencast that was shift-command-forward slash. I would rather it be displayed as "⇧⌘/" rather than "⇧⌘?". I also use commands that involve only the shift modifier with another key, so maybe another prefs checkbox to always show shift explicitly as a separate key press along with the other key(s) pressed instead of showing the modified shifted result. In "menu style" mode I would rather these show as "⇧O" to indicate which keys I pressed, instead of just the modified capital "O" (⇧ and o). Notice in your screencap above as the listed key shortcuts show "key labels" rather than shifted or unshifted characters: ⌥⇧⌘T - shows shifted T, ⌘⇧0 - shows _un_shifted 0.
@akitchen commented on GitHub (Nov 30, 2019):
I think there might be some exceptions to this rule, such as ⌘+ (common shortcut to zoom in) which is actually ⌘⇧= on most keyboards
So this might need a little more thought, i.e. maybe we need a basic heuristic for letters and numbers and something a bit more curated for other keystrokes?
@akitchen commented on GitHub (Aug 14, 2020):
note https://github.com/keycastr/keycastr/issues/176#issuecomment-673775853 for future reference.
@akitchen commented on GitHub (Sep 15, 2020):
This is actually not a bug, as explained in #176 . We should explore adding an option or two as @toootone suggests in order to allow the user to control this behavior, especially for keystrokes such as ⇧⌘1 which is a member of a common family of keyboard shortcuts. I've been exploring this and unfortunately it's not as simple as it seems, however some additional user options would at least provide more flexibility here.
@akitchen commented on GitHub (Dec 11, 2020):
Changes to address this are on the master branch and will appear in the upcoming 0.9.9 release -> where possible, KeyCastr will prefer to display the unshifted / unmodified key in keystrokes involving the shift or option keys, if an alphanumeric value is available in the event.
@akitchen commented on GitHub (Dec 11, 2020):
@toootone recent changes on master work well for the number row, but not for cases like "⇧⌘/" vs "⇧⌘?" on a US-English keyboard. Those cases are tricky as the addition of "⌥" to "⇧⌘/" ("⌥⇧⌘/") should probably be displayed as "⌥⇧⌘?" as the only other option available within the event data would be "⌥⇧⌘¿"
In other words, the option that would render "⇧⌘/" would also render "⌥⇧⌘¿" without additional logic under the hood. A user option to govern this would probably be named something like "Ignore Modifiers when Shifted" but more investigation is needed to find the right combination of heuristics to apply.
@akitchen commented on GitHub (Dec 11, 2020):
To summarize, I think we need something like:
Ignore Shifted Command Keys-> display "⇧⌘]" instead of "⇧⌘}" (YES by default; this is not how things currently behave)Ignore Modifiers when Shifted-> display "⌥⇧⌘?" instead of "⌥⇧⌘¿" (YES by default; this is how things currently behave as of v0.9.9-pre (master branch as of today))Both of these display options would need to be supported by both visualizers' preference panes.
@akitchen commented on GitHub (Jan 2, 2021):
Improvements were made to this behavior in v0.9.9 -- will continue to think about adding options to the user preferences for finer-grained control
@becauseim commented on GitHub (Jan 7, 2021):
Apologies in advance, as I understand nothing about programming and software development, but keycastr in the latest version still does not display the keys pressed, but the characters that are displayed when typing, when Shift is pressed.
It's not at all clear how to use this for screencasting. Obviously, there is no reason to display the characters if the keyboard shortcuts are shown for programs where no typing takes place, but quick actions are performed by keyboard shortcuts.
Why can't the option to display Shift + 1 be added in the same way as Cmd + 1 ?
Simply add such an option to the settings.
@akitchen commented on GitHub (Jan 7, 2021):
As stated in my other comments, Shift-1 is actually a ! keystroke on a US-English keyboard. This varies depending on locale-specific keyboard layouts. Shift-1 is not a command, but a normal keystroke which yields a ! within the eventing system. Command-Shift-1 is represented differently as it is actually a command keystroke, and in that case the 1 is available in the event (along with the !) and the software can choose which to display.
So again, and in short, what you are asking for doesn't seem to be possible @becauseim .
@akitchen commented on GitHub (Jan 10, 2021):
What this boils down to is the need to support two different modes -- displaying keycaps vs what's been input to the system during typing. The keycap information (what @becauseim is asking for with the ability to display shift-1 on a US keyboard) isn't available in the input event KeyCastr gets from macOS, but I see a way to translate this using other frameworks. Some time is needed to test to ensure it works correctly in different locales.
@becauseim commented on GitHub (Jan 11, 2021):
great! I'm ready to participate in the test on the russian localization
@akitchen commented on GitHub (Feb 11, 2021):
@becauseim I'd be interested in hearing how v0.9.10 works for you, if you are using a keyboard and/or locale other than US-EN. Thanks!
@leana8959 commented on GitHub (Jun 23, 2023):
Hi,
I'm wondering if there's a way to override some specific key combinations so that, when specified, keycastr shows the shifted version of the key combination, while showing the raw keystrokes for the rest?
I'm asking this because when I use vim, the keystroke
(would not be shown as a symbol but asshift9. This is hard to read, since the vim motions are conceptualized with symbols and not individual keystrokes. Furthermore,shift9clear the display when using the svelte theme: the key sequenceci(would becomeshift9, becauseciis wiped from the display.I would suggest having an editable list where user can add a list to override. For example, override
shift9to(, and keycastr would replace the output whereshift9to(.What do you think? Also, should I open a new issue about this? I think it would greatly improve the experience, since I mainly use this to explain to people about vim motions :P
Thank you and have a nice day :)
@akitchen commented on GitHub (Jun 23, 2023):
Hi @leana8959 ,
Thank you for the comment. I was a little confused at first, however I see from glancing at vim cheat sheets online that the shift-9 keystroke is commonly referred to as "(". This is a bit tricky, because to see "(" when shift-9 is pressed, you are effectively asking to revert the changes involved in addressing this original issue which I don't think would be agreeable in the general case.
Should KeyCastr be displaying the keycaps pressed or the key which results from those key-presses after modifiers (such as shift, option/alt) are applied? We've taken the position that KeyCastr is for displaying the key caps pressed by default, not the translated keys, but I can certainly understand the confusion (and there are other desired exceptions to this, such as #183)
Thinking more specifically about a vim mode (or even worse, emacs mode), I think we might need a different visualizer altogether. The APIs are there, we just need someone who is interested in building something and contributing back.
Meanwhile, the simplest option would be a toggle for showing translated keys vs original key caps pressed. This is the spirit of #187 which is indeed on the list, after improvements to the mouse click visualizer.
@leana8959 commented on GitHub (Jun 24, 2023):
Thanks for the reply!
I totally understand, I just subscribed to the issues mentioned you mentioned.
I don't have any experience in Objective-C, but maybe one day I'll try to understand how this works or test out features related to this. Thanks :)
@fmaddenflx commented on GitHub (Nov 21, 2023):
I think this should definitely be an option, with a checkbox in the Preferences!