[Smtk-developers] Harmonizing ParaView and SMTK Views

David Thompson david.thompson at kitware.com
Mon Jul 3 09:45:52 EDT 2017


Hi all,

I've been examining the issues involved with integrating SMTK views into ModelBuilder (and thus ParaView). Overall, PV views and SMTK views are not incompatible, but do have some different assumptions.

* PV views expect most data to live on the server, while SMTK's current views (the attribute view and its specialized child that presents operator attributes) live on the client.
* SMTK's Qt extension expects to manage a single attribute-view widget per qtUIManager. It's unclear to me whether creating multiple qtUIManagers attached to the same attribute system would accomplish.
* We could add a new SMTK view type for PV render windows, but that could make maintaining ModelBuilder more complicated because changes to PV's render view might then require SMTK changes.

I have a prototype showing some progress (screenshot attached; branch on gitlab.kitware.com/dcthomp/{smtk,cmb}.git, named attribute-view in both repos). What these branches do is
1. enable multiple views by not overwriting qtCMBMainWindow.ui's central widget.
2. add a new PV behavior that exposes PV's empty-view type-selector without also adding point/cell-selection buttons to the render view (which we don't want by default because CMB is in block-selection mode by default).
3. create a new subclass of ParaView's pqView named pqAttributeView (pqSMTKView would be more accurate); a server-side view object (an instance of vtkSMTKAttributeView) associated with the proxy; and a dummy, XML-only representation for this view. Unlike other views in PV, this view does not track the active dataset; instead it is passed a qtUIManager (more on this below) whose top-level SMTK-view it displays on the client.
4. configure pqAttributeView to emit a signal when it is initialized; ModelBuilder connects this signal to SimBuilder so that when a new template is loaded every existing pqAttributeView is informed of the new qtUIManager.

The branch does *not* 

1. incorporate all of John and Haocheng's multi-view work (yet).
2. disable the dockable "Attribute" panel.

The issues that need to be resolved are:

1. A qtUIManager instance (such as the one created by SimBuilder when loading an attribute) can have only a single QWidget view, but ParaView allows multiple views of the same type. So, right now if you create 2 SMTK attribute views, all but the most-recently-created one will be a blank QWidget.

2. The signal connecting SimBuilder to pqAttributeView instances assumes that new pqAttributeViews should always display the currently-loaded simulation -- but another use case would be to display the active model's operator view, or more generally to allow views of multiple attribute systems at a time. Yet another use case would be to allow views to focus on a particular attribute in an attribute system (e.g., a material view, a BC view, an IC view, a solver-parameter view). In this latter use-case, there would not be a single, top-level view in an attribute file, which goes against the current convention.

3. Either we need to expand SMTK's ViewInfo objects to allow a view to be a render-view of model-entities or change the PV behavior mentioned above to be more explicit about what types of PV views we allow.

4. There's still not a clear path for items in a pqAttributeView's attribute to employ server-side PV widgets. The difficulty is that PV uses a dock-panel (the property inspector) to enable/disable widgets, which are only shown for the active pipeline object. However, in ModelBuilder, items in pqAttributeView which might be associated to 3D widgets would display those widgets in a different PV view (the render view). If we change visibility of a 3-D widget in the attribute view, which render-view would that affect?

	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170703/8d92fe8b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-07-01 at 23.11.59.png
Type: image/png
Size: 523319 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170703/8d92fe8b/attachment-0001.png>


More information about the Smtk-developers mailing list