|Anonymous | Login | Signup for a new account||2016-02-09 17:22 EST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002557||Slicer4||Core: GUI||public||2012-09-24 06:03||2013-04-10 12:38|
|Target Version||Slicer 4.3.0||Fixed in Version||Slicer 4.3.0|
|Summary||0002557: Models hierarchy: whenever the eye is clicked on a node complex hierarchy, the whole interface refreshes collapsing all nodes|
|Description||Loading the NAC brain atlas, http://cigl.spl.harvard.edu/publications/bitstream/download/3732 [^] , if I expand all the nodes to the third level, or any other, where the prosencephalon is divided into telencephalon and diencephalon and click the eye on any of those to make them invisible. The whole slicer GUI refreshes: all the views go to black for a short while and all the hierarchy gets collapsed again.|
PS: Sometimes the changes in opacity and color for all the hierarchical children does not work until a screen refresh is forced
|Steps To Reproduce||- Download the atlas http://cigl.spl.harvard.edu/publications/bitstream/download/3732 [^] |
- Load the scene brain-atlas-hierarchy.mrml
- Go to the models module
- Click on the + button of the hierarchy "Hierarchy root" to find the node brain
- click on + to find rhombencephalon, midbrain and prosencephalon
- click on + of the prosencephalon to find telencephalon and diencephalon
- click on the eye corresponding to diencephalon to make it invisible
- watch all the nodes collapse again
|Tags||No tags attached.|
|Attached Files||abdomencrashbacktrace.txt [^] (18,838 bytes) 2013-02-04 09:38 [Show Content]|
The problem here is that changing the Visibility is done as "Batch Process".
Because the Model scene model is doing LazyUpdate, when the scene ends the batchprocess state, the model is entirely re-populated, which looses the expand/collapse properties).
edited on: 2012-09-24 12:45
qMRMLSceneModel::updateScene should fire a signal before and after repopulating itself.
qMRMLSortAndFilterProxyModel should listen to this signal and propagate it.
qMRMLTreeView should listen to its model, and on sceneAboutToBeUpdated, it should save a list of all the expanded nodes. And on sceneUpdated it should restore the expansion of the nodes that where previously expanded (if they still exist).
As a side note,
vtkMRMLScene::StartState/EndState(vtkMRMLScene::BatchProcessState); shouldn't be done in qMRMLTreeView::toggleVisibility() but in vtkMRMLModelHierarchyLogic::SetChildrenVisibility() instead.
|The views should keep track of the open/close state of the tree and then restore it (if it is still valid) after the data changes. Also they should scroll to the same point.|
edited on: 2012-11-09 05:27
To expand/collapse nodes, you need to do it through the QTreeView API via QModelIndexes :
There is currently no mechanism in qMRMLTreeView to save/restore the expand/collapse state of the tree.
[...]Steve summarizes the user behavior of what I explained in more details when I wrote:
qMRMLTreeView should listen to its model, and on sceneAboutToBeUpdated, it should save a list of all the expanded nodes. And on sceneUpdated it should restore the expansion of the nodes that where previously expanded (if they still exist)
The main idea is to convert expanded indexes into a list of nodes (for saving the state), and convert back the list of nodes into indexes to expand (for restoring the state).
So qMRMLTreeViewPrivate should probably have a new member variable: a vtkCollection* of nodes to expand.
|I did some elementary work on this to understand how things are wired. Thanks to Julien for his suggestions. I will add the functionality to save and restore the state for the tree view.|
Pushed fix to: https://github.com/sankhesh/Slicer/commit/4f1ed29803aa9463b526ee0da583ea55169b2b1e [^]
Pushed changes: https://github.com/sankhesh/Slicer/commit/2557-Hierarchy-visibility-preservation [^]
Kindly review them and if it is alright, I will merge the two commits before pushing to master.
|Fixed in r21523 (http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21523 [^])|
edited on: 2012-12-21 13:56
Testing svn 21524.
Right clicking and adding a model hierarchy closes the hierarchy I'm adding it to in the Models module with that brain atlas scene (didn't occur in my simple test with fewer models and creating a whole new hierachy though).
Dropping models onto a new hierarchy doesn't cause it to expand, has to be done manually (the hierachy node GetExpanded() returns 1).
The annotations module also uses the tree view and I'm finding that if I close a ruler hierarchy and then add another fiducial to an expanded hierarchy, the ruler hierarchy opens up automatically. I'm checking for the expand all and expand to level commands that I'd spotted previously and not finding them so far.
Found a culprit:
qMRMLTreeView.cxx: has 3 calls to expandToDepth(2), in:
I'll check the annotations code ot make sure I'm not resetting the mrml sceen too often (in bug 1735, Julien suggests returning if the mrml scene is the same in setMRMLScene).
The Annotations module is calling refreshTree when nodes are added, which is calling setMRMLScene which is expanding the tree to depth 2. If I take out that call (or put the check for changed mrml scene pointer there), the tree doesn't collapse, but I'm back to the problem of when I add a new hierarchy node that it's not expanded by default in the tree.
deals with the state of the checkbox so that it's in synch with the Expanded state of the hierarchy node, but I'm back to the bug of adding a new hierarchy has it collapsed in the tree view by default.
Added a new bug to address this issue: 2840
The three atlas test is failing on scene close after restoring scene views in the first atlas:
Attaching the debugger, the problem seems to be that the Clear call on the mrml scene gets to the scene model catching the scene closed event and calling qMRMLSceneModel::onMRMLSceneClosed, which calls this->updateScene, where the fist thing that's done is
which triggers qMRMLTreeView::saveTreeExpandState but the node passed to the qMRMLSortFilterProxyModel::filterAcceptsNode method has a null id, causing a seg fault.
I couldn't quite see where to catch the fact that the scene has been closed and the tree expansion state doesn't need to be saved, could you take another look at it?
Ref: http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21523 [^]
|@Nicole, could you please outline the steps you used to reproduce the bug by attaching a debugger to the test?|
run "--no-splash" "--testing" "--ignore-slicerrc" "--python-code" "import slicer.testing; slicer.testing.runUnitTest(['/projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/Slicer-build/Applications/SlicerApp/Testing/Python', '/projects/birn/nicole/Slicer42/Slicer/Applications/SlicerApp/Testing/Python'], 'AtlasTests')"
Attaching the back trace.
edited on: 2013-03-13 11:35
Pushed topic to https://github.com/sankhesh/Slicer/commits/2557-Failing-Atlas-Tests [^]
|Made the suggested changes. Fixed.|
Reminder sent to: finetjul
Hi Julien, looking at the patch. Looks good. Do you have any comments? Thanks
edited on: 2013-03-19 11:27
The fix doesn't deal with the underlying event issue I noted in note 7757 , and I ran across a similar crash again when restoring a scene view. In that case the node was not null, but it's id was null and searching for it in the hidden nodes list caused a crash.
 http://na-mic.org/Mantis/view.php?id=2557#c7757 [^]
|@Nicole: Thanks for commenting. Does the crash occur following the "Steps To Reproduce" reported above ? If not, could you provide Sankhesh with udpated data and steps allowing to reproduce the crash ?|
Narrowed down the crash when it didn't occur through a few steps of the automated test.
Download this .mrb file (accessible via the Brain Atlas test from the Testing, Test Cases, Atlas Tests module):
Load the .mrb file
Enter the Models module first, then enter the Scene Views module.
Select the "Visual System" scene and click Restore.
There's a non zero possibility something's wrong with the visual system scene view.
edited on: 2013-04-01 11:36
Pushed changes to: https://github.com/sankhesh/Slicer/commits/2557-Failing-Atlas-Tests [^]
The last commit ensures the tree expansion state is saved before batch processing starts and is restored after batch processing ends.
Kindly review and test.
|That commit fixed the crash in the Brain Atlas test, and reviewing the code, it looks like it's dealing with the scene restore case more gracfully. Thanks!|
|Fixed: http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21881 [^]|
edited on: 2013-04-10 12:44
And the full atlas test is passing on some machines now (as opposed to none):
The failed ones are mainly due to leaks: http://slicer.cdash.org/testDetails.php?test=3712405&build=84400 [^]
Some others are simply reporting an "exit abnormally error":
Jc: Reporting of error on windows seems to have some issue. Other information should be displated in addition to the "exit abnormally error"
factory-south-win7.kitware has a few tests that fail that way:
http://slicer.cdash.org/viewTest.php?onlyfailed&buildid=84455 [^] [^]
|2012-09-24 06:03||demian||New Issue|
|2012-09-24 06:03||demian||Status||new => assigned|
|2012-09-24 06:03||demian||Assigned To||=> nicole|
|2012-09-24 10:36||nicole||Assigned To||nicole => finetjul|
|2012-09-24 10:36||nicole||Category||Module ModelMaker => GUI|
|2012-09-24 12:30||finetjul||Note Added: 0006194|
|2012-09-24 12:38||finetjul||Note Added: 0006195|
|2012-09-24 12:39||finetjul||Assigned To||finetjul => sankhesh|
|2012-09-24 12:45||finetjul||Note Edited: 0006195|
|2012-10-30 11:03||pieper||Note Added: 0006922|
|2012-11-06 08:04||jcfr||Target Version||=> Slicer 4.3.0|
|2012-11-09 04:55||jcfr||Note Added: 0007132|
|2012-11-09 05:27||finetjul||Note Edited: 0007132|
|2012-11-15 08:49||sankhesh||Note Added: 0007245|
|2012-12-12 09:25||sankhesh||Status||assigned => confirmed|
|2012-12-19 15:51||sankhesh||Note Added: 0007561|
|2012-12-19 15:51||sankhesh||Status||confirmed => feedback|
|2012-12-20 08:44||sankhesh||Note Added: 0007562|
|2012-12-20 11:15||sankhesh||Note Added: 0007563|
|2012-12-20 11:15||sankhesh||Status||feedback => resolved|
|2012-12-20 11:15||sankhesh||Fixed in Version||=> Slicer 4.2.3|
|2012-12-20 11:15||sankhesh||Resolution||open => fixed|
|2012-12-21 06:23||nicole||Note Added: 0007566|
|2012-12-21 06:38||nicole||Note Edited: 0007566|
|2012-12-21 12:09||nicole||Note Edited: 0007566|
|2012-12-21 13:56||nicole||Note Edited: 0007566|
|2012-12-24 14:32||sankhesh||Relationship added||related to 0002841|
|2012-12-26 11:55||nicole||Relationship added||related to 0001735|
|2013-01-29 09:53||nicole||Note Added: 0007757|
|2013-01-29 09:53||nicole||Status||resolved => assigned|
|2013-01-29 09:53||nicole||Resolution||fixed => reopened|
|2013-02-03 11:19||sankhesh||Note Added: 0007792|
|2013-02-04 09:38||nicole||Note Added: 0007797|
|2013-02-04 09:38||nicole||File Added: abdomencrashbacktrace.txt|
|2013-03-13 11:34||sankhesh||Note Added: 0008119|
|2013-03-13 11:35||sankhesh||Note Edited: 0008119|
|2013-03-14 10:54||sankhesh||Note Added: 0008121|
|2013-03-19 10:55||jcfr||Note Added: 0008156|
|2013-03-19 11:24||nicole||Note Added: 0008163|
|2013-03-19 11:25||jcfr||Relationship added||related to 0003007|
|2013-03-19 11:27||jcfr||Note Edited: 0008163|
|2013-03-19 11:29||jcfr||Note Added: 0008164|
|2013-03-22 09:17||nicole||Note Added: 0008204|
|2013-04-01 11:35||sankhesh||Note Added: 0008276|
|2013-04-01 11:36||sankhesh||Status||assigned => feedback|
|2013-04-01 11:36||sankhesh||Note Edited: 0008276|
|2013-04-08 14:00||nicole||Note Added: 0008351|
|2013-04-09 07:34||sankhesh||Note Added: 0008353|
|2013-04-09 07:34||sankhesh||Status||feedback => resolved|
|2013-04-09 07:34||sankhesh||Fixed in Version||=> Slicer 4.3.0|
|2013-04-09 07:34||sankhesh||Resolution||reopened => fixed|
|2013-04-10 10:45||nicole||Note Added: 0008366|
|2013-04-10 10:45||nicole||Status||resolved => closed|
|2013-04-10 12:04||jcfr||Note Added: 0008369|
|2013-04-10 12:19||nicole||Note Added: 0008370|
|2013-04-10 12:20||jcfr||Note Added: 0008371|
|2013-04-10 12:38||nicole||Note Added: 0008372|
|2013-04-10 12:40||jcfr||Note Deleted: 0008372|
|2013-04-10 12:40||jcfr||Note Deleted: 0008371|
|2013-04-10 12:40||jcfr||Note Deleted: 0008370|
|2013-04-10 12:40||jcfr||Note Deleted: 0008369|
|2013-04-10 12:44||jcfr||Note Edited: 0008366|
|Copyright © 2000 - 2016 MantisBT Team|