SMTK Project Menu

Simulation Modeling Toolkit (SMTK)
1

I’m getting some ideas together for an SMTK Project menu to consolidate the separate copies of menu code found in several plugins. The current thinking is outlined below and subject to change.

The SMTK project menu has 5 top-level items:

Project
  Open Project
  Recent Projects =>
  New Project...
  Save Project
  Close Project

Applications and plugins will register their project type

The function to register a project with the menu will include arguments for:

  • The project type string (e.g., “ace3p”, “truchas”, “wavetank”), which must be unique.
  • A public label (“ACE3P”, “Truchas”, “OpenFOAM Wave Tank”)
  • The name of the project’s “create” operation (string)
  • Optional name of the project’s “read” operation (string). Default smtk::project::Read
  • Optional name of the project’s “write” operation (string). Default smtk::project::Write

Future: Include the “unregister project” function. Not needed for present use cases.

Menu visibility and title depend on the number of registered projects

  • If no projects are registered, the menu is not displayed.
  • If one project is registered, the menu’s title is the project’s label.
  • If more than one project are registered, the title reverts back to “Project”. Also the “New” item switches to a submenu with one item for each project type.

The underlying QMenu item will be accessible to application/plugin code.

This is for customization. For example, the ACE3P menu includes additional menu items “Add Stage”, “Login to NERSC”, “Submit Analysis Job”, and “Launch Remote ParaView Server”. Let’s hope everyone uses this feature with caution.

The “New Project…” item will bring up a standard dialog for setting the project directory.

It will have 3 fields for the project name, the “workspace” directory (full path), and the project directory itself (full path).

project-menu

  • Future: projects should be able to substitute their own dialog
  • Future: if the project create dialog requires additional input besides the directory, maybe we can/should embed the operation view below the directory fields?

The SMTK project menu will enforce the “one project only” paradigm.

  • The project plugin will include a static object to store the current project (publicly accessible).
  • Future: add an option to relax the one-project constraint?

The SMTK project menu will replace the current “File” ==> “New Project…” menu item.

In case anyone knew that even existed…

Future: The “Recent Projects” menu should be updated to sort by project type

Because registering multiple project types is a developer use case, we can defer.

2

I would like to avoid any project-specific menus. Open/Save/New/Recent should be able to handle anything (projects or individual resources). The only exception would be File→Close, and that shouldn’t be needed until we can really handle closing a single resource in a project without problems.

3

Also, in terms of a “New Project” dialog, any operation in the CreatorGroup will result in its dialog being popped up. Put the generic smtk::project::Create operation in the smtk::operation::CreatorGroup and you will have the generic version. If a project has a special version, then put it in the creator group. As long as they are in separate plugins, applications can choose which is available to users by choosing which subset of plugins to package.

Edit: I will add this to an upcoming MR that includes some project + task edits.