13c7b06308
EMotionFX has user-customizable hotkeys. These hotkeys are registered by individual plugins, and then the user can set what they want the hotkey to be. The way this was implemented was by reimplementing `keyPressEvent` and `keyReleaseEvent` for each widget that used customizable hotkeys, and in there call `KeyboardShortcutManager::Check` to see if key press matched any existing hotkey mapping. However, the main Editor has behavior that prevents events from reaching EMotionFX's `keyPressEvent` method, if a keypress matches a hotkey that is also used by the main Editor. This is due to the global event filter defined in `ShortcutDispatcher::eventFilter`. This event filter takes a Qt `Shortcut` event, and will re-dispatch that event to all parent widgets of a given receiver. So if a parent widget, like the main Editor, *does* have a QAction that matches a given key sequence, that widget will receive the event, the event is marked as processed, and no `KeyPress` event is ever sent to the original widget where the event occurred. All this means that processing hotkeys in a `keyPressEvent` won't work reliably. The main editor defines a hotkey for the `delete` key, so that can never be received in a `keyPressEvent` by any child widget of the Editor. This change removes all the hotkey logic from the `keyPressEvent` methods, and replaces them with `QAction` instances. Hotkeys are defined with `QAction::setShortcut`, and added to each widget that they apply to. In addition, the `KeyboardShortcutManager` class had to be adjusted to suit this new way of defining the hotkeys. It now has a pointer to each `QAction*` that can have a customizable hotkey. It has also been greatly simplified, since it can use a `QKeySequence` instead of separate variables for `int key; bool hasCtrlModifier; bool hasAltModifier`. Applying user-defined hotkeys now has to be done after the hotkeys are registered from a plugin. It is the plugin's responsibility to reload the user-defined hotkeys after registering all of its actions.