Improve Hotkey System

[Yusyuriv]

What's the PR

• Change the some shortcuts to customizable.
• Added UserControl's for Hotkeys (Card, Expander, Hotkey Display, HotkeyControl)
• Change the design of the Hotkey control to a modern design instead of a TextBox.
• Simplifies the addition code of hotkey items as much as possible.
• The hotkey list on the welcome page has been changed to show only a portion of the fixed hotkeys.
• Closes feat: ✨ bind Ctrl+W and Ctrl+S to previous/next (#2189) #2190

Todo

• Make sure that the button styling is correct.
• Reimplement the old functionality (ability to change the hotkey on click)
• Figure out how to map Action to HotKeyMapper.OnToggleHotkey without creating a local method that calls it.
• Replace old syntax everywhere this component was used with the new syntax.
• Adjust Hotkey List in Wizard Window
• The window does not close when you press the Reset and Delete buttons.
• Delete HotkeyControl(Small Size) and Change the HotkeyControl2 to HotkeyControl

Things to consider

• assigning two shortcuts to a function (Should be available in the future.)
  • We've made the keys that will be utilized the most, and some that were previously double-set, available for double-setting.
• Alignment property (right-left reverses control orientation)
  • We replaced it with a modal popup.

Test Cases

• The changeable hot key must function properly.
• A list of shortcut keys within the Welcome Page is displayed normally.
• The window does not close when you press the Reset and Delete buttons.
• The hot key registration window outside the hot key area must operate.
  • Welcome Window 2nd Page
  • Custom Query Hotkey Window

Todo in separate PR

• Hot keys that have already been set by other function, should not be registered.
  • Decided to let another PR handle this topic.

[onesounds]

@Flow-Launcher/team

• Check out the shortcut entries and defaults and let us know if you disagree.
• We'll be working on a feature that prevents registration of already registered keys in a separate PR.

[VictoriousRaptor]

Why are they separated? and BTW the default value should be the same as current behavior.

[onesounds]

Why are they separated? and BTW the default value should be the same as current behavior.

1. usually no changes are needed except for navigation and autocomplete, I moved these two to the front because they are the most needed. The rest of the keys are intentionally hidden because I don't think users need all those key changes, and not all of them are changeable. (It's more like key descriptions where only some keys are changeable.) Previously, there were no key descriptions except in the wizard window, so I thought this menu should have them. It's this way because if I moved only changeable keys to the front and fixed keys to the back, the prioritization would be weird. I didn't want to show all the keys to the general user that they don't need to change unless they are a power user.

2.I developed this feature because I think the current default key setup is wrong. I've been opposed to the tab shortcut(as autocomplete) since it was introduced, and we've had constant requests to allow tab to be used for navigation ever since. (we had kept the tab key pinned to autocomplete, so other people have consistently put in their own shortcuts to keep tab and use navigation. These features were unknown and unexplained except to those who observed the PR. I found 3 "next item" selection hotkeys and 2 "prev item" selection hotkeys that I didn't know about. )

tab and shift+tab are the default navigation controls in Windows. This is right for most users who need to use the keyboard(like blinds), and since we are basically a Windows program, these should be the default. Of course, we are also a program that is close to shell commands, and since we are a power user program, we should definitely support these operations. Considering the percentage of users who use the shell and the percentage of users who don't use the shell at all, we should have tab as navigation. (I left CTRL+TAB as the default, since I hadn't decided what to do with autocomplete in the end).

I considered providing a preset button that converts to legacy settings for legacy users ("shell-friendly users Preset" Button, to be precise), but I don't know how to make one, so I'm stopping there for now. I don't want to force regular users to do key changes because of legacy support., and I don't want to make them go through this rekeying behavior. I think this is something a power user using the shell would do, so this default value is correct.

We had to spend a very long time discussing this feature and eventually had to create a change feature to resolve all the issues. Some of the defaults (like CTRL+TAB) are of course modifiable, but I wouldn't keep the legacy form as the default. This is non-negotiable. If you disagree with this PR, even with this explanation, buy TEKKEN8 and invite me over. Let's talk fist to fist. 🧙

[VictoriousRaptor]

Why are they separated? and BTW the default value should be the same as current behavior.

1. usually no changes are needed except for navigation and autocomplete, I moved these two to the front because they are the most needed. The rest of the keys are intentionally hidden because I don't think users need all those key changes, and not all of them are changeable. (It's more like key descriptions where only some keys are changeable.) Previously, there were no key descriptions except in the wizard window, so I thought this menu should have them. It's this way because if I moved only changeable keys to the front and fixed keys to the back, the prioritization would be weird. I didn't want to show all the keys to the general user that they don't need to change unless they are a power user.

2.I developed this feature because I think the current default key setup is wrong. I've been opposed to the tab shortcut(as autocomplete) since it was introduced, and we've had constant requests to allow tab to be used for navigation ever since. (we had kept the tab key pinned to autocomplete, so other people have consistently put in their own shortcuts to keep tab and use navigation. These features were unknown and unexplained except to those who observed the PR. I found 3 "next item" selection hotkeys and 2 "prev item" selection hotkeys that I didn't know about. )

tab and shift+tab are the default navigation controls in Windows. This is right for most users who need to use the keyboard(like blinds), and since we are basically a Windows program, these should be the default. Of course, we are also a program that is close to shell commands, and since we are a power user program, we should definitely support these operations. Considering the percentage of users who use the shell and the percentage of users who don't use the shell at all, we should have tab as navigation. (I left CTRL+TAB as the default, since I hadn't decided what to do with autocomplete in the end).

I considered providing a preset button that converts to legacy settings for legacy users ("shell-friendly users Preset" Button, to be precise), but I don't know how to make one, so I'm stopping there for now. I don't want to force regular users to do key changes because of legacy support., and I don't want to make them go through this rekeying behavior. I think this is something a power user using the shell would do, so this default value is correct.

We had to spend a very long time discussing this feature and eventually had to create a change feature to resolve all the issues. Some of the defaults (like CTRL+TAB) are of course modifiable, but I wouldn't keep the legacy form as the default. This is non-negotiable. If you disagree with this PR, even with this explanation, buy TEKKEN8 and invite me over. Let's talk fist to fist. 🧙

Sounds very reasonable. Bad at FTG so I agree with you.:)

[VictoriousRaptor]

Closes #2190