Context menus in SMTK

Simulation Modeling Toolkit (SMTK) Design
1

Problem statement

We should add context menus to SMTK’s user-interface extensions. The resource panel and 3-D render window would both benefit from them.

ParaView now exposes customizable context menus. A starting point exists in aeva, but it is specific to aeva.

What SMTK should present is a framework for applications to add context menu items. In SMTK, the upcoming task class provides the context.

Proposed design

Context menus in ParaView are built on demand (at the time the user right-clicks in the 3-D window). We can extend the base class for context-menu items to provide a variant that takes a QAbstractModelIndex object from a QAbstractItemView (instead of information about the blocks picked in the 3-D view) and use the same class to create context menus for the resource panel or other Qt tree/list widgets.

We want to subset context-menu items by those applicable to the current task. This can be accomplished simply by examining the active task at the time the extension is asked to generate menu items.

Because ParaView’s mechanism has menu-item generators provide an integer priority (and invokes them in order of descending importance), a context-menu plugin may provide items for all tasks or a single task.

This design would only require modifications to existing code – specifically the resource panel – to iterate the set of menu-item generators and invoke the signature specific to the QAbstractItemWidget.

A base menu-item class could provide some commonly-used features:

  • a method to create QAction objects from smtk::operation::Operation classes so that operations can be invoked from the context menu. (NB: This might be better to add elsewhere since it could also be useful for toolbars and a “tool palette panel.”)
  • a set of default menu items (create/close a resource, hide/show a component, deselect everything, select all) that task-specific plugins could invoke as needed.
2

@Ryan_Krattiger You had some comments/criticisms that might still be relevant. My goal is make things as simple as possible and have menus that give precedence to

  • the application first (by choosing what plugins to load)
  • the workflow/project second (by choosing additional plugins to load or unload)
  • the active task third (inside the implementation of each context menu)
  • the user fourth (inside the implementation of context menus, by examining QSettings to see which menu items to hide or possibly reorder)

While CMB might choose to provide a default context menu even when no workflow is chosen, other applications should have the ability to completely disable them.

3

@dcthomp think what you have laid out here makes a lot of sense. My biggest issue before was I thought you were talking about requiring a Task to populate the entire context-menu vs having a task have the option to modify a context menu. I think the proposed priority you have here makes sense.

4

Great, because that’s what’s implemented already. :slight_smile: