Here are some broad plans on how to customize descriptive phrases for RGG. The basic idea is to make the resource panel inherit qtBaseView and use its XML configuration to control what the panel displays. Then a ParaView-aware and RGG-aware selection observer can change what is rendered and selectable.
The qtResourceBrowser (inherited by pqSMTKResourceBrowser) should itself inherit qtBaseView and accept configuration via the smtk::view::View class. The specific things that should be configurable:
- which smtk::view::PhraseModel subclass to use for its QAbstractItemModel;
- whether to use an intermediate QSortFilterProxyModel and add GUI controls (a search text entry and sort control buttons) to the panel;
- which smtk::view::SubphraseGenerator subclass to use (and any configuration controls that are required);
Custom RGG PhraseModel subclass
PhraseModel subclasses determine what phrases make up the top-level items of a QAbstractItemModel in a QTreeView. RGG wants this to be a fixed set corresponding to functional groups (pins, ducts, assemblies, cores). For the purpose of this discussion, let’s say the new class is named
Customizable subphrase generator
Rather than hardcode a subphrase generator to list pins under the
smtk::session::rgg::PhraseModel's top-level “pins” item, we should create a new class (say
smtk::view::QueryPhraseModel for this discussion). That class could hold a
map<std::string, std::string> that uses top-level phrase
title() strings as keys and returns query-strings to pass to
Note that the subphrase generator is responsible for implementing both the
subphrasesForCreatedObjects() methods. The former is called when the view is first created or a tree item expanded ‒ it must provide an ordered list of subphrases on demand; the latter is invoked when SMTK operations report newly-created objects (components) in their results ‒ it must provide new phrases and their locations corresponding to each new object, but only where the parent phrase already exists.
RGG selection behavior
To provide RGG users with control over what is visualized, a selection observer can identify when a pin/duct/assembly/core is selected and update component visibility in ParaView (as well as change the camera as needed).