View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002557Slicer4Core: GUIpublic2012-09-24 06:032013-04-10 12:38
Assigned Tosankhesh 
PlatformOSOS Version
Product Version 
Target VersionSlicer 4.3.0Fixed in VersionSlicer 4.3.0 
Summary0002557: Models hierarchy: whenever the eye is clicked on a node complex hierarchy, the whole interface refreshes collapsing all nodes
DescriptionLoading the NAC brain atlas, [^] , 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 [^]
- 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
TagsNo tags attached.
Attached Filestxt file icon abdomencrashbacktrace.txt [^] (18,838 bytes) 2013-02-04 09: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
finetjul (administrator)
2012-09-24 12: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).
finetjul (administrator)
2012-09-24 12:38
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.

pieper (administrator)
2012-10-30 11: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.
jcfr (administrator)
2012-11-09 04:55
edited on: 2012-11-09 05: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()
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.

sankhesh (developer)
2012-11-15 08: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.
sankhesh (developer)
2012-12-19 15:51

Pushed fix to: [^]

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

Pushed changes: [^]

Kindly review them and if it is alright, I will merge the two commits before pushing to master.
sankhesh (developer)
2012-12-20 11:15

Fixed in r21523 ( [^])
nicole (administrator)
2012-12-21 06:23
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

nicole (administrator)
2013-01-29 09:53

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
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: [^]
sankhesh (developer)
2013-02-03 11:19

@Nicole, could you please outline the steps you used to reproduce the bug by attaching a debugger to the test?
nicole (administrator)
2013-02-04 09: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.
sankhesh (developer)
2013-03-13 11:34
edited on: 2013-03-13 11:35

Pushed topic to [^]
Kindly review.

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

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

Reminder sent to: finetjul

Hi Julien, looking at the patch. Looks good. Do you have any comments? Thanks
nicole (administrator)
2013-03-19 11:24
edited on: 2013-03-19 11: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] [^]

jcfr (administrator)
2013-03-19 11: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 ?
nicole (administrator)
2013-03-22 09: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): [^]
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.
sankhesh (developer)
2013-04-01 11:35
edited on: 2013-04-01 11:36

Pushed changes to: [^]

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.

nicole (administrator)
2013-04-08 14: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!
sankhesh (developer)
2013-04-09 07:34

Fixed: [^]
nicole (administrator)
2013-04-10 10:45
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: [^]

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

- Issue History
Date Modified Username Field Change
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 - 2017 MantisBT Team
Powered by Mantis Bugtracker