From bob.obara at kitware.com Tue Nov 1 12:14:17 2016 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 1 Nov 2016 09:14:17 -0700 Subject: [Cmb-users] Rulers in CMB Message-ID: <6A9B67D7-C092-4A83-83CB-24163F1BB005@kitware.com> While playing with the ruler mechanism I was having a problem trying to figure out which point on the ruler would be snapped when pressing p - Maybe it should highlight the point that would be snapped? Also how do you toggle the points to be snapped (other than selecting the point in the ruler box)? Perhaps there should be a key that toggles the point to be snapped? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Nov 2 14:08:20 2016 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 2 Nov 2016 11:08:20 -0700 Subject: [Cmb-users] Rulers in CMB In-Reply-To: <6A9B67D7-C092-4A83-83CB-24163F1BB005@kitware.com> References: <6A9B67D7-C092-4A83-83CB-24163F1BB005@kitware.com> Message-ID: <91DCFE05-C64B-47B2-96A6-2655BDEFBB2F@kitware.com> Actually I played around with this further - there is a way using command (1 or 2) on Mac or control (1 or 2) - The instructions do need to be updated to let mac users know they need to use command not control. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Nov 1, 2016, at 9:14 AMPDT, Bob Obara wrote: > > While playing with the ruler mechanism I was having a problem trying to figure out which point on the ruler would be snapped when pressing p - Maybe it should highlight the point that would be snapped? Also how do you toggle the points to be snapped (other than selecting the point in the ruler box)? Perhaps there should be a key that toggles the point to be snapped? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Nov 2 19:57:17 2016 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 2 Nov 2016 16:57:17 -0700 Subject: [Cmb-users] (Possible) Managers in CMB Message-ID: Hi All, While traveling I was thinking what types of managers would exist in a CMB-based application. Here is an initial list with some ideas as to what their role could be - Feel free to comment. I will probably work on some simple use cases next to show how they interact with each other. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CMB Managers.png Type: image/png Size: 78367 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: [Cmb-users] 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: [Cmb-users] [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: [Cmb-users] [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: [Cmb-users] [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: