Support Keyboard Modifiers

[Rafi Khan]

Suggested by @1resonant

Invoke an alternate behavior if shift/ctrl/alt/option is pressed.

Easy to support but big UX challenge. How do you expose "button variants" in an intuitive way?

[John Colombo]

Working on a full request build-out. don't let it slow you down though, it's a doozy and I know probably couldn't be implemented this version.

[John Colombo]

I see the UX challenge, based on the user determining the type of function for each button before defining the button's action. It may be outside the scope of KBar as it exists currently but I'll document the proposed feature as best I can.

For this modifier key feature to work, the user would need the option to define the type of button (expression, menu item, etc) in the same window as they determine the action of the button, rather than beforehand as KBar currently functions.

Possible functionality: When a user presses "New Button" they are taken directly to a window where the button's type, modifier key, action, icon, etc are all definable in one dialog. This would also allow for more convenient editing of existing buttons, rather restarting the process if the wrong button type is chosen.

Proposed UI/UX Change:

A dropdown (possibly labelled "Modifier Key") would list all the possible combinations of click +/- modifier:

1. Click (default) could be labelled "None"
2. Ctrl/Cmd + Click
3. Alt/Option + Click
4. Shift + Click
5. Ctrl/Cmd + Alt/Option + Click
6. Ctrl/Cmd + Shift + Click
7. Alt/Option + Shift + Click
8. Ctrl/Cmd + Alt/Option + Shift + Click

"+ Click" might not be required, since common sense dictates a button must be clicked, but you never know

Each modifier key combination would have it's own separate Button Type dropdown, Title/Tooltip text box, and primary parameter. When a different modifier key combination is chosen from the dropdown, the other three parameters titles & contents would shift to either blank (if no parameters have been chosen for that modifier key) or to show parameters previously specified. This way, a single button could (for instance) launch a .jsx by default, apply an expression to a property when Ctrl/Cmd is held, apply an effect if Alt/Option held, etc.

Most ideally, each button could also have a separate icon for each modifier, and visually switch when the modifier key is held but before the button is clicked, to inform the user that the button has a modified function. However, this wouldn't be required since generally the modified function is related to the default function.

Use Case 1: Effect + Adjustment Layer with Effect

• By default, a button applies a Curves effect to a selected layer (Button Type: Effect)

• When Shift is held, the same button creates an Adjustment Layer named "Curves Adjustment", adds the Curves effect to the Adjustment layer and places the new Adjustment Layer above the currently selected layer or at the top of the layer stack if no layer is selected. (Button Type: Preset, Scriptlet or .JSX file)

Use Case 2: Overshoot Expression Rig – for optional comp-wide control of expressions

• By default, a button applies an overshoot expression to a selected Position property, and creates expression controls to modify the amount of overshoot, decay, etc. (Button Type: Scriplet or .JSX file)

• When Shift is held, a new Null layer named "Overshoot Control" with visibility turned off is created at the top of the layer stack, and 2 sets of expression controls for overshoot expressions are added. (Button Type: Preset, Scriptlet, or .JSX file)

• When Ctrl/Cmd is held, an expression is added to a selected Position property which references the first set of controls on the "Overshoot Control" Null, allowing the expression to be controlled from the Null's controls. (Button Type: Expression)

• When Alt/Option is held, an expression is added to a selected Position property which references the second set of controls on the "Overshoot Control" Null, allowing the expression to be controlled from the Null's controls. (Button Type: Expression)

Use Case 3: Similar Menu Functions

• By default, a button initiates "Fit to Comp Width" menu item. (Button Type: Menu)

• When Alt/Option is held, the same button initiates "Fit to Comp Height" menu item. (Button Type: Menu)

• When Shift is held, the same button initiates "Fit to Comp" menu item. (Button Type: Menu)

Use Case 4: Similar Effect Alternatives + Adjustment Layers

• By default, a button applies a Tint effect to a selected layer. (Button Type: Effect)

• When Alt/Option is held, the button applies a Tritone effect to the selected layer. (Button Type: Effect)

• When Shift is held, the button creates an Adjustment Layer named "Tint Adjustment", adds the Tint effect to the Adjustment layer and places the new Adjustment Layer above the currently selected layer or at the top of the layer stack if no layer is selected. (Button Type: Preset, Scriptlet or .JSX file)

• When Alt/Option + Shift is held, the button creates an Adjustment Layer named "Tritone Adjustment", adds the Tritone effect to the Adjustment layer and places the new Adjustment Layer above the currently selected layer or at the top of the layer stack if no layer is selected. (Button Type: Preset, Scriptlet or .JSX file)

Benefits:

1. Quantity: Increases the amount of button functions available with less screen real estate, as each button has eight potential functions instead of one. Critical for some users.

2. Flexibility: This allows a user to create workflows consistent with their AE skill level/preferences, whether they are most comfortable applying presets vs scriptlets, incorporating other users' .jsx files, or keeping multiple variants of an expression for different uses.

Other notes/potential issues:

A headless .jsx file that has it's own keyboard modifiers scripted into it, ie. headless versions of Adam Plouff's ButtCapper, would be handicapped if used in conjunction with this feature, unless the KBar modifiers could be disabled. Perhaps the modifier key dropdown could have a 9th option of "Disable Modifier Keys" or "Use Script Modifiers"

[Lars Jandel]

As the modifier keys are already working, how is the status / possibility of having alternative icons for hovering in conjunction with pressed modifier keys? Maybe it doesn't have to be implemented in the UI right away, if there is a specified naming convention for the icons, like scriptArgumentModifier.svg and KBar will grab existing ones in a defined folder when creating the item.

Thanks, Lars.

[Rafi Khan]

@larsjandel This is a great suggestion and I looked into it. The only way to get this to work is if KBar has focus first and then this can work. It's a really klunky experience unfortunately.

[Lars Jandel]

Ah okay, I see what you mean. Of course you could have KBar grab the focus on mouseover (I guess you tried that?), but this kind of "aggressive" behaviour isn't always optimal as it can block some other functionality, when taking the focus away from AE itself or other previously focused scripts. Thanks for giving it a shot. ...just checked with scriptUI: It can recognise modifier keys and do changes in the UI even if not being in focus. ...okay, did not test an icon change, but text change does work at least. Cheers, Lars.