Note that it might seem to do odd things to keep the state consistant and prevent us from getting into invalid states or triggering shorcuts when we shouldn't. Some of these include:
- If the new chain would trigger a shortcut, the shortcut will be synthetically triggered with a keyup.
- If the manager is Manager.state.isAwaitingKeyup to trigger anything (Manager.state.untrigger), the shortcut will be synthetically triggered with a keyup.
- If there are still non-modifier keys being pressed, the manager will wait until they are all released before allowing keys to be added to the chained again.
- Modifiers will stay in the first chord if they are still being pressed according to Key.press. This makes it possible for the user to trigger multiple shortcuts without releasing a modifier. This can result in potentially strange behavior for shortcuts longer than one chord, as further chords can be started without releasing the modifiers. If you don't like this, you can pass {preserveModifiers: false} to force the user to release the modifiers.
- If there are still modifier keys being pressed, the manager will add them to the last chord, unless you pass preserverModifiers: false.
- **If keys are currently being held (Key.pressed is true), note that the manager's state and the key state state may not match. This is usually not a problem with normal key presses, but... **
- If using virtualPress/virtualToggle, the keys might remain pressed, potentially causing issues. In those cases you can use the Manager.listener to keep track of whether keys are virtually pressed or not (virtually pressed keys have no events), and unpress the ones you should.
- Setting a [] chain is slightly different than setting a [[]] chain to keep the behavior of the manager consistent on the next key press.
- When you set [], the function will also set Manager.state.nextIsChord to true, so it knows to insert a chord on the next key press.
- When you set [[]], it will set it to false, since the chord already exists.
Safely sets the manager's chain.
Note that it might seem to do odd things to keep the state consistant and prevent us from getting into invalid states or triggering shorcuts when we shouldn't. Some of these include: - If the new chain would trigger a shortcut, the shortcut will be synthetically triggered with a keyup. - If the manager is Manager.state.isAwaitingKeyup to trigger anything (Manager.state.untrigger), the shortcut will be synthetically triggered with a keyup. - If there are still non-modifier keys being pressed, the manager will wait until they are all released before allowing keys to be added to the chained again. - Modifiers will stay in the first chord if they are still being pressed according to Key.press. This makes it possible for the user to trigger multiple shortcuts without releasing a modifier. This can result in potentially strange behavior for shortcuts longer than one chord, as further chords can be started without releasing the modifiers. If you don't like this, you can pass
{preserveModifiers: false}
to force the user to release the modifiers. - If there are still modifier keys being pressed, the manager will add them to the last chord, unless you passpreserverModifiers: false
. - **If keys are currently being held (Key.pressed is true), note that the manager's state and the key state state may not match. This is usually not a problem with normal key presses, but... ** - If using virtualPress/virtualToggle, the keys might remain pressed, potentially causing issues. In those cases you can use the Manager.listener to keep track of whether keys are virtually pressed or not (virtually pressed keys have no events), and unpress the ones you should. - Setting a[]
chain is slightly different than setting a[[]]
chain to keep the behavior of the manager consistent on the next key press. - When you set[]
, the function will also set Manager.state.nextIsChord totrue
, so it knows to insert a chord on the next key press. - When you set[[]]
, it will set it tofalse
, since the chord already exists.