Skip to content

Conventions for Option Keys #246

Open
@rpatters1

Description

@rpatters1

As part of listing the differences between menu items, configuration items, and user settings, I realized that another tool in the tool box is Option keys when invoking the script. When Jari, Tobias, and I originally started our plugin projects, almost every plugin had a (modal) dialog box. We early on agreed on a convention that invoking a plugin with Option or Shift key should suppress the dialog box and use defaults or most recent settings. I subsequently added the ability to reverse that, which I see as the preferable choice in many cases (especially modal dialogs).

I did not resist @cv-on-hub's choice of creating extra menu items to suppress dialog boxes, because that's easier for a new user, but it would make for much less cluttered menus if we could adopt this convention of option key invoking (or suppressing) the dialog. Once users are trained on this it becomes automatic. In a user interface, "intuitive" equals "what the interface trains users to do" and if we could agree on consistent behavior of the option keys, they would be more useful.

I would propose the following conventions:

  1. If a dialog box is modeless and if the user is likely to be changing the settings for each invocation of the script, then the default should be to open the dialog and option/shift key should suppress the dialog and use the last settings. An example of this case is transposition dialogs.
  2. If a dialog box is modal or if the user is unlikely to be changing the settings for each invocation of the script, the default should be to suppress the dialog and use the last settings and option/shift should open the dialog. An example of this case is the Patterson Beams plugin (though it doesn't actually behave that way by default because reasons.)
  3. In either case, if the dialog box has never been opened by the user it might open the first time regardless of option/shift state, unless there is a sensible default. Persistent user settings could potentially obviate the need ever to open it again.

FWIW: the current transpose_* scripts have already implemented case 1. above, and it is embodied in the FCXCustomLuaWindow:RunModeless method. So if you use RunModeless you get it automatically by default. (RunModeless forces the dialog to open if finenv.RetainLuaState is false, but it could be enhanced to use user settings as well.)

A concern is whether Keyboard Maestro can access a menu option with option key pressed.

@jwink75 @ThistleSifter

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions