From bob.obara at kitware.com Tue Mar 3 11:58:27 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 3 Mar 2015 11:58:27 -0500 Subject: [Smtk-developers] Qwt for plotting Message-ID: Hi All, I was looking at adding some plotting capabilities for Simple Expression Views and came across this: http://qwt.sourceforge.net Its LGPL and seems pretty complete for plotting. Any comments? 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 Tue Mar 3 12:03:30 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 3 Mar 2015 12:03:30 -0500 Subject: [Smtk-developers] Help with shadowed variable warning Message-ID: <050B23AE-0519-4C36-885C-A0E31931A4BA@kitware.com> Hi all, Could whoever wrote the discrete session's vtkCMBParserV4 class please verify that this fix for the shadowed variable is correct? https://github.com/vibraphone/SMTK/commit/006606ccbce0b4650d3a1b339c50ba63bafeea4c I could not tell from the source whether a distinction between the declarations was intended or not. Thanks, David From david.thompson at kitware.com Tue Mar 3 12:15:28 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 3 Mar 2015 12:15:28 -0500 Subject: [Smtk-developers] Qwt for plotting In-Reply-To: References: Message-ID: > I was looking at adding some plotting capabilities for Simple Expression Views and came across this: > http://qwt.sourceforge.net > > Its LGPL and seems pretty complete for plotting. > > Any comments? I have seen it around for many years but never used it. (It is a matter of taste, but I dislike the visual style and these days would prefer using d3.js inside a QWebView.) It does seem to be actively maintained and have a lot of nice features. I don't see anything on its web page about interaction... did you intend for users to draw curves and, if so, does it support that? David From marcus.hanwell at kitware.com Tue Mar 3 12:53:08 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Mar 2015 12:53:08 -0500 Subject: [Smtk-developers] Qwt for plotting In-Reply-To: References: Message-ID: On Tue, Mar 3, 2015 at 12:15 PM, David Thompson wrote: >> I was looking at adding some plotting capabilities for Simple Expression Views and came across this: >> http://qwt.sourceforge.net >> >> Its LGPL and seems pretty complete for plotting. >> >> Any comments? > > I have seen it around for many years but never used it. (It is a matter of taste, but I dislike the visual style and these days would prefer using d3.js inside a QWebView.) It does seem to be actively maintained and have a lot of nice features. I don't see anything on its web page about interaction... did you intend for users to draw curves and, if so, does it support that? > I used it during my postdoc some (2007-2009), and it was generally disappointing. I would be interested if it has improved, but I am with David and dislike the visual style used (which I couldn't find a way to fix/change when I tried). Marcus From david.thompson at kitware.com Tue Mar 3 14:50:43 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 3 Mar 2015 14:50:43 -0500 Subject: [Smtk-developers] SMTK mesh Message-ID: Hi all, As discussed, our options for smtk::mesh are 1. Finish abstracting MOAB out of Rob's smtk::mesh branch. Make mesh part of the SMTKCore library with MOAB as an optional, system/superbuild-provided library. This is the most preferable but would require a fair amount of work for dealing with element ranges efficiently. Testing with and without MOAB would be required. 2. Include MOAB in SMTK's third-party directory and either build it (with I/O dependencies like HDF5/NetCDF as optional, system/superbuild-provided) or allow an external MOAB to be given. On my system, building MOAB without any supporting I/O libraries takes about 12 seconds, which is not bad when compared to all of SMTK with Python wrapping on (about 170 seconds). The larger concern is that MOAB would add about 7 MiB of source code to the repo, while SMTK is currently at 33 MiB including git history; even if we remove MOAB from third-party later, it would be a big bump in the git history. Testing thoroughly would mean building with internal MOAB (no I/O), with internal MOAB (and external I/O libs) and with an external MOAB -- this would take more ongoing effort to test. However, this option requires less development effort up front. 3. Finally, we could make smtk::mesh its own optional library, dependent on SMTKCore. This is the least desirable solution because it leaves meshes as second-class citizens compared to attributes, models, and exporters -- but it requires the least work. Any strong opinions? I prefer #1 if it is feasible in the time frame. David From robert.maynard at kitware.com Tue Mar 3 16:23:13 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Mar 2015 16:23:13 -0500 Subject: [Smtk-developers] SMTK mesh In-Reply-To: References: Message-ID: As far as #1 goes I will also have to add a small layer between io and smtk::mesh::moab to allow us to build without moab. I expect this will be handled by a new abstract class ( maybe smtk::io::Reader/Writer? ) that smtk::mesh::Interface manages. On Tue, Mar 3, 2015 at 2:50 PM, David Thompson wrote: > Hi all, > > As discussed, our options for smtk::mesh are > > 1. Finish abstracting MOAB out of Rob's smtk::mesh branch. Make mesh part > of the SMTKCore library with MOAB as an optional, > system/superbuild-provided library. This is the most preferable but would > require a fair amount of work for dealing with element ranges efficiently. > Testing with and without MOAB would be required. > > 2. Include MOAB in SMTK's third-party directory and either build it (with > I/O dependencies like HDF5/NetCDF as optional, system/superbuild-provided) > or allow an external MOAB to be given. On my system, building MOAB without > any supporting I/O libraries takes about 12 seconds, which is not bad when > compared to all of SMTK with Python wrapping on (about 170 seconds). The > larger concern is that MOAB would add about 7 MiB of source code to the > repo, while SMTK is currently at 33 MiB including git history; even if we > remove MOAB from third-party later, it would be a big bump in the git > history. Testing thoroughly would mean building with internal MOAB (no > I/O), with internal MOAB (and external I/O libs) and with an external MOAB > -- this would take more ongoing effort to test. However, this option > requires less development effort up front. > > 3. Finally, we could make smtk::mesh its own optional library, dependent > on SMTKCore. This is the least desirable solution because it leaves meshes > as second-class citizens compared to attributes, models, and exporters -- > but it requires the least work. > > Any strong opinions? I prefer #1 if it is feasible in the time frame. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Mar 10 16:13:53 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 10 Mar 2015 16:13:53 -0400 Subject: [Smtk-developers] Qt model tree changes Message-ID: Hi Yumin et al., I think the following should get the tree view updating properly after operators are applied: 1. The smtk::model::SubphraseGenerator class should have a new pure virtual method: virtual void updateWithOperatorResult( DescriptivePhrase::Ptr treeRoot, OperatorResult result) = 0; The implementation should be in the SimpleModelSubphrases class (or a new subclass of it). The method would find the owning model and session of each entity listed in the result and (being careful to call areSubphrasesBuilt() before calling subphrases() on each descriptive phrase) descend the root until it finds the item's proper place in the tree. At that point, updateWithOperatorResult() would trigger callbacks before and after inserting new DescriptivePhrase(s) into the tree. It would trigger these callbacks like so: 2. The SimpleModelSubphrases class should provide a callback mechanism for indicating when phrases are being changed. The callback observers would be stored in the SimpleModelSubphrases class in a new protected ivar: std::set m_phraseTriggers; and new methods added mirroring the model Manager and Operator classes so that users can register for notifications: void observe(PhraseEventType event, PhraseCallback functionHandle, void* callData); void unobserve(PhraseEventType event, PhraseCallback functionHandle, void* callData); void trigger(PhraseEventType event, const smtk::model::DescriptivePhrasePtr src); The PhraseEventType, PhraseCallback, and PhraseTrigger types would mirror the ConditionCallback types in smtk/model/Event.h. So, inside updateWithOperatorResult(), it would look like: this->trigger( std::make_pair(WILL_ADD_CHILD, ENTITY_PHRASE), parentPhrasePtr, childIndex, numberOfChildren); // Create new DescriptivePhrase(s) here this->trigger( std::make_pair(DID_ADD_CHILD, ENTITY_PHRASE), parentPhrasePtr, childIndex, numberOfChildren); 3. The owner/creator of the QEntityItemModel and SimpleModelSubphrases instances (the pqSMTKModelPanel in CMBv4) should register callbacks for the above triggers (i.e., call simpleModelSubphrases->observe() for {WILL,DID}_{ADD,DEL,MOD}_CHILD events) and have the callback methods invoke new methods on QEntityItemModel that do the following (for addition in this example): void QEntityItemModel::willAddSubphrases(...) { this->beginInsertRows(qidx, 0, nrows); } void QEntityItemModel::didAddSubphrases(...) { this->endInsertRows(); emit dataChanged(qidx, qidx); } These callbacks are registered just once when the delegate and QEntityItemModel are created. I do not think modified items need a before+after callback... just running "emit dataChanged" on the Qt index of the descriptive phrase should be enough. But both addition and deletion need the 2-phase will{Add,Del} and did{Add,Del} calls. 4. Whenever the application creates an Operator, it should call smtk::model::OperatorPtr op; pqSMTKModelPanel* panel; op->observe(DID_OPERATE, pqSMTKModelPanel::processOperatorResult, panel); and implement pqSMTKModelPanel::processOperatorResult() to invoke the simpleModelSubphrases->updateWithOperatorResult() method with the operator result. 5. Change the Operator::operate method to add items to the OperatorResult attribute that indicate which entries in the "entities" item were added and which were just modified. Having this done automatically by the operator instead of by operation-specific subclasses greatly reduces the maintenance cost of the operator classes. The list of "expunged" entities is already separate from those modified and added. David