From bob.obara at kitware.com Mon Oct 3 10:22:30 2016 From: bob.obara at kitware.com (Bob Obara) Date: Mon, 3 Oct 2016 10:22:30 -0400 Subject: [Smtk-developers] Building on Xcode 8.0 Issues Message-ID: <2F4DD557-AA9D-4731-BD50-5FA7F1EDDDCB@kitware.com> Hi All, When building on XCode 8.0 I get the following error: /Users/obara/Projects/Kitware/Builds/CMBSuperBuildParaViewMasterXC8.0/superbuild/opencv/src/modules/videoio/src/cap_qtkit.mm:46:9: fatal error: 'QTKit/QTKit.h' file not found #import ^ 1 error generated. ninja: build stopped: subcommand failed. CMake Error at /Users/obara/Projects/Kitware/Builds/CMBSuperBuildParaViewMasterXC8.0/superbuild/sb-opencv-build.cmake:43 (message): Failed with exit code 1 I think QT in this case is QuickTime (not Qt). 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 david.thompson at kitware.com Thu Oct 6 17:26:04 2016 From: david.thompson at kitware.com (David Thompson) Date: Thu, 6 Oct 2016 17:26:04 -0400 Subject: [Smtk-developers] Operators, debugging, and logs Message-ID: <74A1FAE6-6302-40C2-BA5A-2A6902CD7C8A@kitware.com> Hi SMTK devs, I am writing to let you know about some recent changes to model operators that may be of interest: 1. The base operator now includes a protected ivar named m_debugLevel . It is 0 by default. You may set it in the debugger and/or at the top of your operator's operateInternal() method, then use it during an operation to output additional information. If people are interested, it should also be possible to expose the debug level as an advanced item in the base operator attribute so that debugging can be turned on/off from the ModelBuilder UI on a per-operator basis. 2. The model manager owns an instance of smtk::io::Logger, available via log(). ModelBuilder now displays all messages added to the log from the moment the operation starts until the result of the operation. This is great for providing feedback to users via smtkErrorMacro, smtkWarningMacro, smtkDebugMacro, and smtkInfoMacro. 3. The base Operator class now has a virtual generateSummary() method that generates a log message from the operator's outcome. You may override it to provide information specific to your operation. With the change above, ModelBuilder now provides feedback to the user for each operation performed. David From david.thompson at kitware.com Fri Oct 7 17:42:41 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 7 Oct 2016 17:42:41 -0400 Subject: [Smtk-developers] Auxiliary geometry branch Message-ID: Hi all, There's now a branch named aux-geom in my (dcthomp's) smtk and cmb repos on gitlab. It includes the following changes: 1. The VTK model multiblock source now has top-level blocks that organize entities by the dimension of their geometric locus. This greatly improves the visual quality of renderings and image-baselines for tests are much more repeatable. 2. A new entity type, AuxiliaryGeometry, is available. Each instance is intended to represent a. Scene geometry to be loaded from a file (when a "url" string property is set); ** or ** b. Construction, datum, and/or preview geometry (when a Tessellation is associated). 3. Descriptive phrases now include auxiliary geometry instances owned by a model. 4. A new operator "add auxiliary geometry" is available in all sessions that creates an auxiliary geometry instance and assigns it to a parent model. Limitations include + Selections in the 3d view and model-browser list-view will not work until ModelBuilder is updated to use a vtkDataObjectTreeIterator with the flat index stored in the UUID->block_id map. + The file types support for auxiliary geometry is currently limited to obj, vtp, vti, vtu, and vtm. + Dropdowns in the operator panel do not allow you to select auxiliary geometry as an item value yet. + The "add auxiliary geometry" operator cannot yet create hierarchical auxiliary geometry (i.e., auxiliary geometry that is a child of something other than the model) due to the above and other issues. + Entity, Group, and Volume coloring do not appear to work. Group coloring definitely requires further effort as the method for enumerating model entities in the multiblock source has been changed. + Image and other non-polygonal data will be loaded but not rendered. Changes are needed for the composite mapper in order for this to be supported. Ken has outline how to make them and thinks it will be about a week of effort. A picture is attached for your viewing pleasure. :-) David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-10-07 at 5.32.23 PM.png Type: image/png Size: 573250 bytes Desc: not available URL: From bob.obara at kitware.com Thu Oct 20 17:54:08 2016 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 20 Oct 2016 17:54:08 -0400 Subject: [Smtk-developers] Operator View Message-ID: <26E82D98-DBCA-40CA-9F69-DC4B0F101E87@kitware.com> Hi All, So I?m designing the operator view base calls - which would be used as the default GUI for an operator. I just wanted to describe some of the design: 1. It assumes that the operator is defined by a single attribute definition/attribute - the old way was reusing the existing instanced attribute view. The reason for doing this is to know where to grab the association information. 2. In addition to the top level view attribute it will also have a. auto_apply attribute indicating that by default this operation does not need to use the View but instead can be automatically applied. This can be over ridden by a setting on the ?operation manager? b. no_apply attribute indicating that the operator does not need an apply button 3. If the operation requires more than one model entity - a list box will be displayed instead of a combo box. (if it takes in a single entity than it will still use a combo box) If you have any comments or suggestions let me know! 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 david.thompson at kitware.com Thu Oct 20 18:14:39 2016 From: david.thompson at kitware.com (David Thompson) Date: Thu, 20 Oct 2016 18:14:39 -0400 Subject: [Smtk-developers] Operator View In-Reply-To: <26E82D98-DBCA-40CA-9F69-DC4B0F101E87@kitware.com> References: <26E82D98-DBCA-40CA-9F69-DC4B0F101E87@kitware.com> Message-ID: <61D894CE-A2F8-4AA6-A28D-5218FE44FA7B@kitware.com> Hi Bob, > So I?m designing the operator view base calls - which would be used as the default GUI for an operator. I just wanted to describe some of the design: > > 1. It assumes that the operator is defined by a single attribute definition/attribute - the old way was reusing the existing instanced attribute view. The reason for doing this is to know where to grab the association information. Does this mean that each view will have its own attribute-instance? I like it, but be aware that it will lead to frustration in some cases: people sometimes expect a way to re-apply the same operation again (with the same arguments which are not the default arguments) but the view will appear to have forgotten their previous configuration. For instance, saving to a file requires a filename. The attribute definition cannot provide a meaningful default, so every time users go to save, they will be asked to enter the same filename. One workaround would be to provide operators with a virtual "auto-populate" method that would get called to set up the operator's attribute (for example, by filling in the filename from the "url" string property on the selected model/session). > 2. In addition to the top level view attribute it will also have > > a. auto_apply attribute indicating that by default this operation does not need to use the View but instead can be automatically applied. This can be over ridden by a setting on the ?operation manager? > > b. no_apply attribute indicating that the operator does not need an apply button > > 3. If the operation requires more than one model entity - a list box will be displayed instead of a combo box. (if it takes in a single entity than it will still use a combo box) > > If you have any comments or suggestions let me know! I don't know how easy it would be with Qt, but it would be nice for each operator that can both be auto-applied and accept non-default item-values to accept 2 triggers ("apply with defaults" or "customize first"), so that you don't have to change a setting in the "operation manager" twice (once before the operation you want to customize and once afterwards). David From bob.obara at kitware.com Thu Oct 20 18:35:47 2016 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 20 Oct 2016 18:35:47 -0400 Subject: [Smtk-developers] Operator View In-Reply-To: <61D894CE-A2F8-4AA6-A28D-5218FE44FA7B@kitware.com> References: <26E82D98-DBCA-40CA-9F69-DC4B0F101E87@kitware.com> <61D894CE-A2F8-4AA6-A28D-5218FE44FA7B@kitware.com> Message-ID: Hi Dave, 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 Oct 20, 2016, at 6:14 PMEDT, David Thompson wrote: > > Hi Bob, > >> So I?m designing the operator view base calls - which would be used as the default GUI for an operator. I just wanted to describe some of the design: >> >> 1. It assumes that the operator is defined by a single attribute definition/attribute - the old way was reusing the existing instanced attribute view. The reason for doing this is to know where to grab the association information. > > Does this mean that each view will have its own attribute-instance? I like it, but be aware that it will lead to frustration in some cases: people sometimes expect a way to re-apply the same operation again (with the same arguments which are not the default arguments) but the view will appear to have forgotten their previous configuration. > No - I was more going after the fact that right now an operator could be defined by multiple attributes (it inherited this functionality because under the covers it uses an instance view which can have multiple attribute definitions). Actually what I would like to do is to change things so that an operator is defined as an attribute definition and an object that can perform the operation - for example a session already has the operators registered - what is missing is the ability to getting the attribute definitions directly from the session instead of instantiating the operator itself. This way we determine what operations are valid based on the entities selected. It would also allow us to hold onto the attribute (which would have the previously entered values). Does that make sense? Bob > For instance, saving to a file requires a filename. The attribute definition cannot provide a meaningful default, so every time users go to save, they will be asked to enter the same filename. > > One workaround would be to provide operators with a virtual "auto-populate" method that would get called to set up the operator's attribute (for example, by filling in the filename from the "url" string property on the selected model/session). > >> 2. In addition to the top level view attribute it will also have >> >> a. auto_apply attribute indicating that by default this operation does not need to use the View but instead can be automatically applied. This can be over ridden by a setting on the ?operation manager? >> >> b. no_apply attribute indicating that the operator does not need an apply button >> >> 3. If the operation requires more than one model entity - a list box will be displayed instead of a combo box. (if it takes in a single entity than it will still use a combo box) >> >> If you have any comments or suggestions let me know! > > I don't know how easy it would be with Qt, but it would be nice for each operator that can both be auto-applied and accept non-default item-values to accept 2 triggers ("apply with defaults" or "customize first"), so that you don't have to change a setting in the "operation manager" twice (once before the operation you want to customize and once afterwards). > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Oct 20 19:37:44 2016 From: david.thompson at kitware.com (David Thompson) Date: Thu, 20 Oct 2016 19:37:44 -0400 Subject: [Smtk-developers] Operator View In-Reply-To: References: <26E82D98-DBCA-40CA-9F69-DC4B0F101E87@kitware.com> <61D894CE-A2F8-4AA6-A28D-5218FE44FA7B@kitware.com> Message-ID: <3AA8156B-4F08-44B3-B2B5-9AB64CFACD83@kitware.com> Hi Bob, It is possible to get the attribute system from a session already: https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.h#L337 You can then ask for all the definitions that inherit the base "operator" and figure out which operators are applicable to a given selection. David > On Oct 20, 2016, at 18:35, Bob Obara wrote: > > Hi Dave, > > > 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 Oct 20, 2016, at 6:14 PMEDT, David Thompson wrote: >> >> Hi Bob, >> >>> So I?m designing the operator view base calls - which would be used as the default GUI for an operator. I just wanted to describe some of the design: >>> >>> 1. It assumes that the operator is defined by a single attribute definition/attribute - the old way was reusing the existing instanced attribute view. The reason for doing this is to know where to grab the association information. >> >> Does this mean that each view will have its own attribute-instance? I like it, but be aware that it will lead to frustration in some cases: people sometimes expect a way to re-apply the same operation again (with the same arguments which are not the default arguments) but the view will appear to have forgotten their previous configuration. >> > > No - I was more going after the fact that right now an operator could be defined by multiple attributes (it inherited this functionality because under the covers it uses an instance view which can have multiple attribute definitions). > > Actually what I would like to do is to change things so that an operator is defined as an attribute definition and an object that can perform the operation - for example a session already has the operators registered - what is missing is the ability to getting the attribute definitions directly from the session instead of instantiating the operator itself. This way we determine what operations are valid based on the entities selected. It would also allow us to hold onto the attribute (which would have the previously entered values). > > Does that make sense? > > Bob > >> For instance, saving to a file requires a filename. The attribute definition cannot provide a meaningful default, so every time users go to save, they will be asked to enter the same filename. >> >> One workaround would be to provide operators with a virtual "auto-populate" method that would get called to set up the operator's attribute (for example, by filling in the filename from the "url" string property on the selected model/session). >> >>> 2. In addition to the top level view attribute it will also have >>> >>> a. auto_apply attribute indicating that by default this operation does not need to use the View but instead can be automatically applied. This can be over ridden by a setting on the ?operation manager? >>> >>> b. no_apply attribute indicating that the operator does not need an apply button >>> >>> 3. If the operation requires more than one model entity - a list box will be displayed instead of a combo box. (if it takes in a single entity than it will still use a combo box) >>> >>> If you have any comments or suggestions let me know! >> >> I don't know how easy it would be with Qt, but it would be nice for each operator that can both be auto-applied and accept non-default item-values to accept 2 triggers ("apply with defaults" or "customize first"), so that you don't have to change a setting in the "operation manager" twice (once before the operation you want to customize and once afterwards). >> >> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Oct 22 08:17:36 2016 From: david.thompson at kitware.com (David Thompson) Date: Sat, 22 Oct 2016 08:17:36 -0400 Subject: [Smtk-developers] Supressing shiboken warnings Message-ID: Hi Ben (et al.), I submitted a PR on shiboken's smtk-head branch (which is what I believe the CMB superbuild pulls) that will allow us to suppress the remaining warnings that looked like: ** WARNING scope not found for symbol:KWIML_INT_detail_VERIFY_SIGN_::uintptr_t_v1 ** WARNING scope not found for symbol:KWIML_INT_detail_VERIFY_SIGN_::uintptr_t_v1 ** WARNING scope not found for function definition:vtkBuffer::New definition *ignored* The issue was that the messages were being printed straight to cerr instead of passed to the ReportHandler. The patch fixes only those warnings which are actually appearing in SMTK/CMB builds, not all the cerr output. I've also added the necessary magic to smtk/typesystem.xml in [SMTK MR 301](). David [SMTK MR 301]: https://gitlab.kitware.com/cmb/smtk/merge_requests/301 From ben.boeckel at kitware.com Mon Oct 24 10:57:33 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 24 Oct 2016 10:57:33 -0400 Subject: [Smtk-developers] Supressing shiboken warnings In-Reply-To: References: Message-ID: <20161024145733.GA13247@megas.kitware.com> On Sat, Oct 22, 2016 at 08:17:36 -0400, David Thompson wrote: > I submitted a PR on shiboken's smtk-head branch (which is what I > believe the CMB superbuild pulls) that will allow us to suppress the > remaining warnings that looked like: Shiboken is now a tarball (to avoid git cloning all the time), but that is the branch we spin from. Let's get TJ's rebase, the patch sitting in the superbuild, and the warning fix into the next spin. --Ben From david.thompson at kitware.com Mon Oct 24 11:17:19 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 24 Oct 2016 11:17:19 -0400 Subject: [Smtk-developers] Supressing shiboken warnings In-Reply-To: <20161024145733.GA13247@megas.kitware.com> References: <20161024145733.GA13247@megas.kitware.com> Message-ID: <28F066B4-D42D-4FB9-8B67-5294B3F522FE@kitware.com> > On Sat, Oct 22, 2016 at 08:17:36 -0400, David Thompson wrote: >> I submitted a PR on shiboken's smtk-head branch (which is what I >> believe the CMB superbuild pulls) that will allow us to suppress the >> remaining warnings that looked like: > > Shiboken is now a tarball (to avoid git cloning all the time), but that > is the branch we spin from. Let's get TJ's rebase, the patch sitting in > the superbuild, and the warning fix into the next spin. Okidoke. I've merged the PR into smtk-head and added a note for TJ on his branch/PR. David From david.thompson at kitware.com Mon Oct 24 11:25:05 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 24 Oct 2016 11:25:05 -0400 Subject: [Smtk-developers] Polygon branch Message-ID: <18BBE960-F301-4519-B858-BC5F5B8395C3@kitware.com> Hi all, This is just a heads-up that the SMTK polygon session (2-D modeling) is about to receive some updates (once merge-request 301 is approved... probably some time this week): + a new "demote vertex" operator, + a bunch of fixes to the "split edge" operator, and + a fix to the "create all faces" operator so it won't duplicate pre-existing faces. David