* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
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.
Steve Pham
Chris Burel
alexpete