Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002557 [Slicer4] Core: GUI major always 2012-09-24 10:03 2013-04-10 16:38
Reporter demian View Status public  
Assigned To sankhesh
Priority normal Resolution fixed  
Status closed   Product Version
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
Additional Information
Tags No tags attached.
Attached Files txt file icon abdomencrashbacktrace.txt [^] (18,838 bytes) 2013-02-04 14:38 [Show Content]

- Relationships
related to 0002841closedsankhesh Deleting a node from tree view hierarchy in Models module crashes Slicer 
related to 0001735closednicole Annotation widget does not maintain collapsed state after refresh. 
related to 0003007closednicole Models are not listed in the models module 

-  Notes
(0006194)
finetjul (administrator)
2012-09-24 16:30

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).
(0006195)
finetjul (administrator)
2012-09-24 16:38
edited on: 2012-09-24 16: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.

(0006922)
pieper (administrator)
2012-10-30 15:03

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.
(0007132)
jcfr (administrator)
2012-11-09 09:55
edited on: 2012-11-09 10:27

From Julien:

[...]
To expand/collapse nodes, you need to do it through the QTreeView API via QModelIndexes :
QTreeView::isExpanded(), QTreeView::isCollapsed()
QTreeView::expand(), QTreeView::collapse()
signals:
QTreeView::expanded(), QTreeView::collapsed()

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.
[...]

(0007245)
sankhesh (developer)
2012-11-15 13:49

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.
(0007561)
sankhesh (developer)
2012-12-19 20:51

Pushed fix to: https://github.com/sankhesh/Slicer/commit/4f1ed29803aa9463b526ee0da583ea55169b2b1e [^]

Kindly review.
(0007562)
sankhesh (developer)
2012-12-20 13:44

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.
(0007563)
sankhesh (developer)
2012-12-20 16:15

Fixed in r21523 (http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21523) [^]
(0007566)
nicole (administrator)
2012-12-21 11:23
edited on: 2012-12-21 18: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:
setSceneModel
setSortFilterProxyModel
setMRMLScene
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.
qMRMLSceneHierarchyModel::updateItemDataFromNode
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

(0007757)
nicole (administrator)
2013-01-29 14:53

The three atlas test is failing on scene close after restoring scene views in the first atlas:
http://slicer.cdash.org/testDetails.php?test=3344280&build=59605 [^]
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
emit sceneAboutToBeUpdated();
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 [^]
(0007792)
sankhesh (developer)
2013-02-03 16:19

@Nicole, could you please outline the steps you used to reproduce the bug by attaching a debugger to the test?
(0007797)
nicole (administrator)
2013-02-04 14:38

gdb bin/SlicerApp-real
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.
(0008119)
sankhesh (developer)
2013-03-13 15:34
edited on: 2013-03-13 15:35

Pushed topic to https://github.com/sankhesh/Slicer/commits/2557-Failing-Atlas-Tests [^]
Kindly review.

(0008121)
sankhesh (developer)
2013-03-14 14:54

Made the suggested changes. Fixed.
(0008156)
jcfr (administrator)
2013-03-19 14:55

Reminder sent to: finetjul

Hi Julien, looking at the patch. Looks good. Do you have any comments? Thanks
(0008163)
nicole (administrator)
2013-03-19 15:24
edited on: 2013-03-19 15:27

The fix doesn't deal with the underlying event issue I noted in note 7757 [1], 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.

[1] http://na-mic.org/Mantis/view.php?id=2557#c7757 [^]

(0008164)
jcfr (administrator)
2013-03-19 15:29

@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 ?
(0008204)
nicole (administrator)
2013-03-22 13:17

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):
http://slicer.kitware.com/midas3/download?items=10937 [^]
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.
(0008276)
sankhesh (developer)
2013-04-01 15:35
edited on: 2013-04-01 15: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.

(0008351)
nicole (administrator)
2013-04-08 18:00

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!
(0008353)
sankhesh (developer)
2013-04-09 11:34

Fixed: http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21881 [^]
(0008366)
nicole (administrator)
2013-04-10 14:45
edited on: 2013-04-10 16:44

And the full atlas test is passing on some machines now (as opposed to none):
http://slicer.cdash.org/testSummary.php?project=1&name=py_AtlasTests&date=2013-04-10 [^]
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":
http://slicer.cdash.org/testDetails.php?test=3547220&build=84401 [^]

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 [^] [^]


- Issue History
Date Modified Username Field Change
2012-09-24 10:03 demian New Issue
2012-09-24 10:03 demian Status new => assigned
2012-09-24 10:03 demian Assigned To => nicole
2012-09-24 14:36 nicole Assigned To nicole => finetjul
2012-09-24 14:36 nicole Category Module ModelMaker => GUI
2012-09-24 16:30 finetjul Note Added: 0006194
2012-09-24 16:38 finetjul Note Added: 0006195
2012-09-24 16:39 finetjul Assigned To finetjul => sankhesh
2012-09-24 16:45 finetjul Note Edited: 0006195
2012-10-30 15:03 pieper Note Added: 0006922
2012-11-06 13:04 jcfr Target Version => Slicer 4.3.0
2012-11-09 09:55 jcfr Note Added: 0007132
2012-11-09 10:27 finetjul Note Edited: 0007132
2012-11-15 13:49 sankhesh Note Added: 0007245
2012-12-12 14:25 sankhesh Status assigned => confirmed
2012-12-19 20:51 sankhesh Note Added: 0007561
2012-12-19 20:51 sankhesh Status confirmed => feedback
2012-12-20 13:44 sankhesh Note Added: 0007562
2012-12-20 16:15 sankhesh Note Added: 0007563
2012-12-20 16:15 sankhesh Status feedback => resolved
2012-12-20 16:15 sankhesh Fixed in Version => Slicer 4.2.3
2012-12-20 16:15 sankhesh Resolution open => fixed
2012-12-21 11:23 nicole Note Added: 0007566
2012-12-21 11:38 nicole Note Edited: 0007566
2012-12-21 17:09 nicole Note Edited: 0007566
2012-12-21 18:56 nicole Note Edited: 0007566
2012-12-24 19:32 sankhesh Relationship added related to 0002841
2012-12-26 16:55 nicole Relationship added related to 0001735
2013-01-29 14:53 nicole Note Added: 0007757
2013-01-29 14:53 nicole Status resolved => assigned
2013-01-29 14:53 nicole Resolution fixed => reopened
2013-02-03 16:19 sankhesh Note Added: 0007792
2013-02-04 14:38 nicole Note Added: 0007797
2013-02-04 14:38 nicole File Added: abdomencrashbacktrace.txt
2013-03-13 15:34 sankhesh Note Added: 0008119
2013-03-13 15:35 sankhesh Note Edited: 0008119
2013-03-14 14:54 sankhesh Note Added: 0008121
2013-03-19 14:55 jcfr Issue Monitored: finetjul
2013-03-19 14:55 jcfr Note Added: 0008156
2013-03-19 15:24 nicole Note Added: 0008163
2013-03-19 15:25 jcfr Relationship added related to 0003007
2013-03-19 15:27 jcfr Note Edited: 0008163
2013-03-19 15:29 jcfr Note Added: 0008164
2013-03-22 13:17 nicole Note Added: 0008204
2013-04-01 15:35 sankhesh Note Added: 0008276
2013-04-01 15:36 sankhesh Status assigned => feedback
2013-04-01 15:36 sankhesh Note Edited: 0008276
2013-04-08 18:00 nicole Note Added: 0008351
2013-04-09 11:34 sankhesh Note Added: 0008353
2013-04-09 11:34 sankhesh Status feedback => resolved
2013-04-09 11:34 sankhesh Fixed in Version => Slicer 4.3.0
2013-04-09 11:34 sankhesh Resolution reopened => fixed
2013-04-10 14:45 nicole Note Added: 0008366
2013-04-10 14:45 nicole Status resolved => closed
2013-04-10 16:04 jcfr Note Added: 0008369
2013-04-10 16:19 nicole Note Added: 0008370
2013-04-10 16:20 jcfr Note Added: 0008371
2013-04-10 16:38 nicole Note Added: 0008372
2013-04-10 16:40 jcfr Note Deleted: 0008372
2013-04-10 16:40 jcfr Note Deleted: 0008371
2013-04-10 16:40 jcfr Note Deleted: 0008370
2013-04-10 16:40 jcfr Note Deleted: 0008369
2013-04-10 16:44 jcfr Note Edited: 0008366


Mantis 1.1.4[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker