There are a few places where registration happens in SMTK that do not use the new Schwarz counter and plugin management stuff that TJ put in:
- Qt view & item constructors are handled in
smtk::common::Extensionclasses also use old-style static registration
We would like to refactor these so that the API is consistent and takes advantage of the new mechanism.
Qt item and view constructors
With SMTK MR 1753, there is now an
smtk::view::Manager object that is more of a factory than anything else (it creates
SubphraseGenerator instances). We should expand its role to the creation of new views in a GUI-independent way.
Note that unlike the resource Manager (which manages resources but does not require resources to be managed to be useful), the view Manager will be necessary for most views to function properly.
This work will involve the following changes:
smtk::view, rename the
Configurationto avoid name collision/confusion below.
- Create a derived class
smtk:::extension::qtConfiguration, and have it hold a weak pointer to the view
Managerthat created it.
- Create a new
smtk::view::Viewclass and make
- Add a method to
create(const view::Configuration&)that will construct a new
smtk::view::Viewsubclass, passing its constructor the view configuration.
- Create a new
smtk::extension::qtConfigurationclass that inherits
smtk::view::Configuration; its purpose is to take the place of
smtk::extension::ViewInfo(Qt-specific view configuration).
a. Since this object inherits
view::Configuration, it need not own an instance of it. By using emplacement and move semantics, it will be possible for a Qt view containers (i.e., ParaView panels or other application components) to efficiently convert a hierarchy of
smtk::extension::qtConfigurationinstances as needed.
b. This class will own a QLayout dictionary and hold a pointer to a QWidget.
- Add methods to the
view::Managerto register and unregister
- Create a subclass of
smtk::view::Managerthat is specific to Qt -
smtk::extension::qtManager. Beyond the basic view manager, this class will
a. have register and unregister methods for qtItem constructors
b. have register and unregister methods for qtModelView constructors (QTreeView, QListView, etc.)
c. provide methods currently housed in
qtUIManagerthat deal with application-wide configuration information such as colors and settings. Since every view holds a weak pointer to the manager which created it, it is accessible everywhere
qtUIManageris currently used.
- Remove the
qtSMTKUtilitiesclass (the view manager holds custom view constructors and the Qt-specific view manager holds custom item and modelview-widget constructors).
- Remove the
qtUIManagerclass (the Qt-specific view manager,
smtk::extension::qtManager, should replace it).
We have two alternatives:
- a minimal change to the extensions to use the Registrar pattern while maintaining the existing pattern or
- adapting the
smtk::common::Generatorpattern to deal with extension-like behavior.
@tj.corona probably has strong opinions here; this page is a wiki so he can edit this section to provide more details of what he wants to see.