One issue that has recently come to light is that when multiple pqSMTKAttributeItemWidgets (subclasses of qtItem) of the same type are instantiated, they all create QShortcut objects with the same key sequence. When that happens, the shortcuts no longer emit an activated() signal; instead they emit ambiguouslyActivated(). The problem is that these events are also emitted for partial key-sequence matches, so it might be that the signal is emitted first when Ctrl/Cmd is pressed and again when P is pressed.
The question is how to change the UI so that behavior is maximally useful and minimally astonishing. Things that contribute to maximal usefulness:
- ability to have all (or at least some) widgets simultaneously visible in 3-d views so users can position them relative to each other.
- avoid requiring users to switch between panels where different Qt widgets reside in order to get the 3d widget into an editable/responsive state.
- consistent behavior even when widgets of different types (e.g., point and line widgets) both use the same shortcut for edits.
Some possible avenues to explore:
- explicit indication of focus on Qt widgets, synchronized to the picking behavior. Tab order would need some attention.
- explicit indication of focus on 3D PV widgets
- user-directed choice of focus widget in Qt panels (via ternary button: hide, show, interact)
- find a way to deconflict duplicate shortcuts (either by not adding potential conflicts or by resolving conflicts so that only a single widget is allowed to respond to the shortcut).
Other concerns/requirements that have come up since:
- Confusion might occur if users are allowed to edit widgets unrelated to the current task by accident (perhaps several are close to each other and difficult to distinguish). Some possible avenues to explore:
- Only handles whose Qt widgets are visible in a panel should respond to user interaction.
- Use an “alarm” to notify users when interaction is attempted with a 3-d widget not displayed in the panel by flashing the tab where it is located.
- Switch tabs and mark the Qt widgets associated with a 3-d widget whenever a user starts interacting with the 3-d widget.
- Annotate the widgets so they are easily disambiguated and thus there is no confusion.
When evaluating potential interaction techniques, there are several conflicting goals:
- Never prevent the user from doing something; forcing a user to change the application state before performing an action (say, by forcing them to switch tabs) can be frustrating and time consuming.
- Prevent confusion that could be caused by nearby/overlapping widgets.
- Minimize interruptions to the user; instead of pop-up dialogs, use status-bar/console messages. Instead of switching tasks (requiring the user to switch back manually), automatically revert any task-switching required so that it becomes an illustration of the application’s response to the user’s intent.
Some introductory work on this is in SMTK MR 1666. It changes the point-handle widget so that the visibility toggle is a tri-state (ternary) button; when partially checked, the keyboard shortcuts are not added.
This is a temporary workaround to the problem above.
In the longer term, some more ideas (or concrete details on some of the ideas above):
- have widgets display a label on hover (in the 3-d view) showing the SMTK item they control (if any).
- have widgets highlight themselves in the 3-d view when users hover over their Qt editors
- use “spring-loaded” animations to switch to panels/tabs containing widgets being edited in the 3-d view.
- add a ParaView application-wide shortcut manager for view windows so widgets don’t multiple-register shortcuts.