Alternative ALT behaviour #268
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Makes the following changes to the keymap:
1.
Remove all instances where [ALT]+['key'] and ['key'] both map to the same calculator key, freeing up those key combinations for something more useful.
Reasoning: No one is going to press [Alt]+['key'] when it does the same thing as just ['key'], so it is a waste to have it as such, and there are better things that can be done with those key combinations.
This also fixes the following conflict by removing line 150, making [Alt]+[-] map only to '(-)' (negation):
line 103: ,{Qt::Key_Minus | ALT, keymap::neg}
line 150: ,{Qt::Key_Minus | ALT, keymap::minus}
2.
Add instances where mappings using symbols made (on US keyboards) by typing [Shift]+['key'] are also mapped to [Alt]+['key'], in the same way as [Alt]+[2] and [@] are both assigned to the 'x^2' calculator key, and [Alt]+[=] and [+] are both assigned to the '+' calculator key, already.
Reasoning:
Since [Shift] = 'shift' on calculator, it would (arguably) be better to not have to use [Shift] outside of the calculator's usage as it can cause unintended problems.
Noticed some mappings that, at least on Windows boxen, are in conflict with the keyboard shortcuts for the 'Emulation' and 'Flash' menubar items. For reference to any reading this that are unfamiliar, if a letter in a menubar item is underlined, then pressing the [Alt] key while also pressing the key of the underlined letter will cause that particular menuitem to expand, highlighting the first item in its submenu. Firebird has the following shortcuts of this type configured: [E]->'Emulation', [T]->'Tools', [N]->'Snapshot', [F]->'Flash', and [U]->'About'. The 'Docks' menubar item does not have a shortcut assigned to it. Fortunately, both of the conflicts have alternative mappings as well, so removing these lines is of minimal negative impact. Unfortunately, this person has no suggestions for a better mapping, so changing these lines rather than removing them may be difficult.
|
It's a bit tricky as the meaning of the Qt keys can differ based on the host keyboard layout... The changes should work fine with a de QWERTY layout. @adriweb can you check fr/AZERTY? |
|
The only AZERTY I have around here is an M1 MBA but I guess we'll see how it behaves... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Makes the following changes to the keymap:
Remove all instances where [ALT]+['key'] and ['key'] both map to the same calculator key, freeing up those key combinations for something more useful.
Reasoning: No one is going to press [Alt]+['key'] when it does the same thing as just ['key'], so it is a waste to have it as such, and there are better things that can be done with those key combinations.
This also fixes the following conflict by removing line 150, making [Alt]+[-] map only to '(-)' (negation):
line 103: ,{Qt::Key_Minus | ALT, keymap::neg}
line 150: ,{Qt::Key_Minus | ALT, keymap::minus}
Add instances where mappings using symbols made (on US keyboards) by typing [Shift]+['key'] are also mapped to [Alt]+['key'], in the same way as [Alt]+[2] and [@] are both assigned to the 'x^2' calculator key, and [Alt]+[=] and [+] are both assigned to the '+' calculator key, already.
Reasoning:
Since [Shift] = 'shift' on calculator, it would (arguably) be better to not have to use [Shift] outside of the calculator's usage as it can cause unintended problems.