From david.thompson at kitware.com Wed Nov 16 16:35:04 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 16 Nov 2016 16:35:04 -0500 Subject: [Smtk-developers] Changes to SMTK and CMB Message-ID: Hi all, Yumin and I have been working on support for auxiliary geometry; these are now in master and ** ** SMTK and CMB now require you to update both repositories in lock step. ** If you update either, please update both. The changes were made to handle the following use cases: + load and display image data alongside polygonal models; + load geometry to be placed in a scene for a simulation, but not used as a model; + allow creation of construction geometry (not yet implemented); and + load geometry to be instanced in a simulation (instancing not yet implemented). By default, when you use the "add auxiliary geometry" operator, ModelBuilder will create a separate representation for the geometry so that you can control how it is rendered separate from the SMTK model which owns it. To do this, make sure the auxiliary geometry entity you create is selected (highlighted in the tree view) and then click on ModelBuilder's "Display" tab. Attached is an image of DEM data displayed along with an SMTK model of land and water regions created using the contour extraction operator. Please let us know if you have any problems. David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-11-16 at 4.23.48 PM.png Type: image/png Size: 749603 bytes Desc: not available URL: From bob.obara at kitware.com Wed Nov 23 14:18:39 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 23 Nov 2016 14:18:39 -0500 Subject: [Smtk-developers] Proposed change to Attribute and Item Definitions Message-ID: <90D4977A-CBC9-4EB9-B966-E48820D7DE86@kitware.com> Hi All, With CMB 4.1 / SMTK 1.1 nearing completion, we have started working on CMB 5.0/SMTK 2.0. There is one possible change I would like to propose and wanted to get your feedback on concerning how attribute definitions and item definitions are currently defined. The role of these classes are to represent simulation information. The Attribute Definitions representing the conceptual aspect of the information while the Item Definitions representing its structure. Note that how the information is to be represented in a GUI is (for the most part) not part of these classes but is represented in the Views. The one exception are the Labels. They represent the alternative way of displaying the "type" information of the attribute definition and the "name" information of the item definition. Since in 5.0, the GUI generation will support specifying where items should be placed within a View's widgets that are rendering the information, I was wondering if moving the label information into View structure would make more sense. It would allow workflows to customize how the type and name info is displayed (as well as allowing for localization). Along those lines I was wondering if we should support allowing the Workflow the ability to "override" the default values of Items since (based on the assumption that a default values may be workflow specific). Let me know what you think. Happy Thanksgiving! Bob Robert M. O'Bara, MEng. Technical Leader Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 From david.thompson at kitware.com Wed Nov 23 15:03:22 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 23 Nov 2016 15:03:22 -0500 Subject: [Smtk-developers] Proposed change to Attribute and Item Definitions In-Reply-To: <90D4977A-CBC9-4EB9-B966-E48820D7DE86@kitware.com> References: <90D4977A-CBC9-4EB9-B966-E48820D7DE86@kitware.com> Message-ID: > ... There is one possible change I would like to propose and wanted to get your feedback on concerning how attribute definitions and item definitions are currently defined. ... Note that how the information is to be represented in a GUI is (for the most part) not part of these classes but is represented in the Views. The one exception are the Labels. They represent the alternative way of displaying the "type" information of the attribute definition and the "name" information of the item definition. > > Since in 5.0, the GUI generation will support specifying where items should be placed within a View's widgets that are rendering the information, I was wondering if moving the label information into View structure would make more sense. I agree that labels belong with the view, not the items/attributes. > It would allow workflows to customize how the type and name info is displayed (as well as allowing for localization). > > Along those lines I was wondering if we should support allowing the Workflow the ability to "override" the default values of Items since (based on the assumption that a default values may be workflow specific). That seems reasonable. > Happy Thanksgiving! Many happy returns of the morrow! David From john.tourtellott at kitware.com Wed Nov 23 15:27:12 2016 From: john.tourtellott at kitware.com (John Tourtellott) Date: Wed, 23 Nov 2016 15:27:12 -0500 Subject: [Smtk-developers] Proposed change to Attribute and Item Definitions In-Reply-To: References: <90D4977A-CBC9-4EB9-B966-E48820D7DE86@kitware.com> Message-ID: With regard to Label, you could still support it "inline" with the definition, and allow the View to override it. (And in turn, allow a workflow spec to override a view-specified Label, I suppose.) However, I'm not sure I like this, since it is the inverse of the standard css-inheritance paradigm. If we want to keep it simple, I would move it to the view, even though I know I'll complain about it later :) As for workflows overriding default values: - I don't foresee multiple/different workflows sharing the same attribute definitions, but maybe my thinking is too limited here. - If there are use-cases for that (different workflows using variations of the same definitions), then we might want the workflows to override other definition characteristics in addition to the default value. On Wed, Nov 23, 2016 at 3:03 PM, David Thompson wrote: > > ... There is one possible change I would like to propose and wanted to > get your feedback on concerning how attribute definitions and item > definitions are currently defined. ... Note that how the information is to > be represented in a GUI is (for the most part) not part of these classes > but is represented in the Views. The one exception are the Labels. They > represent the alternative way of displaying the "type" information of the > attribute definition and the "name" information of the item definition. > > > > Since in 5.0, the GUI generation will support specifying where items > should be placed within a View's widgets that are rendering the > information, I was wondering if moving the label information into View > structure would make more sense. > > I agree that labels belong with the view, not the items/attributes. > > > It would allow workflows to customize how the type and name info is > displayed (as well as allowing for localization). > > > > Along those lines I was wondering if we should support allowing the > Workflow the ability to "override" the default values of Items since (based > on the assumption that a default values may be workflow specific). > > That seems reasonable. > > > Happy Thanksgiving! > > Many happy returns of the morrow! > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Nov 23 17:11:34 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 23 Nov 2016 17:11:34 -0500 Subject: [Smtk-developers] Proposed change to Attribute and Item Definitions In-Reply-To: References: <90D4977A-CBC9-4EB9-B966-E48820D7DE86@kitware.com> Message-ID: <8F7874C7-4A3F-4497-92C9-29491C1ECE78@kitware.com> Hi John, The one example concerning overriding defaults would be with respects to the Numerics. For example the default pre-conditioner of the solver might differ for different workflows right? Another possible example could be workflows that are idealizations of a more complex workflow? Bob Sent from my iPad > On Nov 23, 2016, at 3:27 PM, John Tourtellott wrote: > > With regard to Label, you could still support it "inline" with the definition, and allow the View to override it. (And in turn, allow a workflow spec to override a view-specified Label, I suppose.) However, I'm not sure I like this, since it is the inverse of the standard css-inheritance paradigm. If we want to keep it simple, I would move it to the view, even though I know I'll complain about it later :) > > As for workflows overriding default values: > I don't foresee multiple/different workflows sharing the same attribute definitions, but maybe my thinking is too limited here. > If there are use-cases for that (different workflows using variations of the same definitions), then we might want the workflows to override other definition characteristics in addition to the default value. > > > >> On Wed, Nov 23, 2016 at 3:03 PM, David Thompson wrote: >> > ... There is one possible change I would like to propose and wanted to get your feedback on concerning how attribute definitions and item definitions are currently defined. ... Note that how the information is to be represented in a GUI is (for the most part) not part of these classes but is represented in the Views. The one exception are the Labels. They represent the alternative way of displaying the "type" information of the attribute definition and the "name" information of the item definition. >> > >> > Since in 5.0, the GUI generation will support specifying where items should be placed within a View's widgets that are rendering the information, I was wondering if moving the label information into View structure would make more sense. >> >> I agree that labels belong with the view, not the items/attributes. >> >> > It would allow workflows to customize how the type and name info is displayed (as well as allowing for localization). >> > >> > Along those lines I was wondering if we should support allowing the Workflow the ability to "override" the default values of Items since (based on the assumption that a default values may be workflow specific). >> >> That seems reasonable. >> >> > Happy Thanksgiving! >> >> Many happy returns of the morrow! >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: