<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi all,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">* 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.</div><div class="">* 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.</div><div class="">* 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.</div><div class=""><br class=""></div><div class="">I have a prototype showing some progress (screenshot attached; branch on <a href="http://gitlab.kitware.com/dcthomp/" class="">gitlab.kitware.com/dcthomp/</a>{smtk,cmb}.git, named attribute-view in both repos). What these branches do is</div><div class="">1. enable multiple views by not overwriting qtCMBMainWindow.ui's central widget.</div><div class="">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).</div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">The branch does *not* </div><div class=""><br class=""></div><div class="">1. incorporate all of John and Haocheng's multi-view work (yet).</div><div class="">2. disable the dockable "Attribute" panel.</div><div class=""><br class=""></div><div class="">The issues that need to be resolved are:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>David</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="32C5CFC0-2880-487B-ACA9-9BB52172148B" width="640" height="434" src="cid:D5E9CAB0-8B9F-48A9-B27E-459BAE9C4F6E@kitware.com" class=""></div></body></html>