Grundlett: Text replacement - "slicerWiki/index.php" to "wiki"

2019-11-21T16:58:28Z

Text replacement - "slicerWiki/index.php" to "wiki"

UpdateBot: Nightly -> 4.10

2018-10-19T00:43:53Z

Nightly -> 4.10

New page

<noinclude>__TOC__</noinclude>
==Slicer backward incompatible changes==

=== Slicer 4.9: Update of VTK version from 9.0 to 8.2 ===

Following [https://github.com/Kitware/VTK/commit/b703d78be3ffd8ae69c319afa0230097ff270f26 kitware/VTK@b703d78be], VTK has updated to use version number 8.2 instead of 9.0. This was discussed in on the VTK mailing list in http://vtk.1045678.n5.nabble.com/Discussion-OK-to-change-VTK-s-version-number-from-9-0-to-8-2-tt5748702.html

At first, this VTK commit and its companion [https://github.com/Kitware/VTK/commit/8a00b357e84eec695bda049216f30f2b76d80855 kitware/VTK@8a00b357e] were both reverted from the [https://github.com/Slicer/VTK/ Slicer/VTK] fork. Then, since having the corresponding changes reverted in VTK was not possible, it was decided to also update Slicer. This was done in the following commits:
* [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27472 r27472]: COMP: Update c++ classes to support building against VTK >= 9 and VTK >= 8.2
* [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27473 r27473]: COMP: Update VTK to include version change from 9.0 to 8.2. Fixes #4623

This means that code depending on VTK must also be updated to include similar fixes.

'''Replace this:'''
#if VTK_MAJOR_VERSION >= 9

'''By this:'''
#if VTK_MAJOR_VERSION >= 9 || (VTK_MAJOR_VERSION >= 8 && VTK_MINOR_VERSION >= 2)

and

'''Replace this:'''
#if VTK_MAJOR_VERSION < 9

'''By this:'''
#if VTK_MAJOR_VERSION <= 7 || (VTK_MAJOR_VERSION <= 8 && VTK_MINOR_VERSION <= 1)

=== Slicer 4.9: ITK_LEGACY_REMOVE is now OFF ===
In preparation to switch to ITK 5.0, we disable legacy functionality in ITK. This might affect some modules which rely on ITK. Take a look at [https://itk.org/migrationv4 ITK 4 migration guide] before [https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/ITK5MigrationGuide.md ITK 5 migration guide].

=== Slicer 4.9: vtkMRMLPlotDataNode renamed to vtkMRMLPlotSeriesNode ===
Plotting was improved in [https://github.com/Slicer/Slicer/commit/082edc40c this commit]

'''Replace this:'''

vtkMRMLPlotDataNode

'''By this:'''
vtkMRMLPlotSeriesNode

=== Slicer 4.9: CMake: Module MIDAS not available ===

The test infrastructure of your project should be updated to use [https://cmake.org/cmake/help/latest/module/ExternalData.html ExternalData] built-in CMake module
instead of the specific <tt>MIDAS</tt> module.

See EMSegment commit [http://viewvc.slicer.org/viewvc.cgi/Slicer3?view=revision&revision=17150 r17150] for an example of transition.

This means that instead of using <tt>midas_add_test</tt> with the <tt>MIDAS{path/to/file.ext.md5}</tt>
syntax for addressing the test data, the function [https://cmake.org/cmake/help/latest/module/ExternalData.html#command:externaldata_add_test ExternalData_add_target] is used by
specifying both <tt>DATA{path/to/file.ext}</tt> and a download target name.

'''Replace this:'''

midas_add_test(NAME test1 COMMAND ...)
midas_add_test(NAME test2 COMMAND ...)

'''By this:'''

ExternalData_add_test(EMSegmentData NAME test1 COMMAND ...)
ExternalData_add_test(EMSegmentData NAME test2 COMMAND ...)

[...]

ExternalData_add_target(EMSegmentData)

A key difference with the former approaches is that instead of adding two tests (one named
<tt><testName>_fetchData</tt> to downoad the data and one running the test command), only one
test is added but a common download target is added at the end using [https://cmake.org/cmake/help/latest/module/ExternalData.html#command:externaldata_add_target ExternalData_add_target]
function.

This means that test data can now be downloaded in parallel (and cached) at build time instead
of testing time.

=== Slicer 4.9: CMake: Module SlicerMacroCheckExternalProjectDependency not available ===

Since the module was removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=26992 r26992], consider updating
your build system to use CMake module <code>ExternalProjectDependency</code>

=== Slicer 4.9: CMake: Module SlicerMacroEmptyExternalProject not available ===

Since the module was removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=26991 r26991]

'''Replace this:'''

<pre>
include(SlicerMacroEmptyExternalProject)

[...]

SlicerMacroEmptyExternalProject("${proj}" "${${proj}_DEPENDENCIES}")
</pre>

'''By this:'''

<pre>
include(ExternalProjectDependency)

[...]

ExternalProject_Add_Empty(${proj} DEPENDS ${${proj}_DEPENDENCIES})
</pre>

=== Slicer 4.9: CMake: Module SlicerBlockSetCMakeOSXVariables not available ===

Since it was renamed to <tt>SlicerInitializeOSXVariables</tt> in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=26982 r26982]

'''Replace this:'''

<pre>
include(SlicerBlockSetCMakeOSXVariables)
</pre>

'''By this:'''

<pre>
include(SlicerInitializeOSXVariables)
</pre>

=== Slicer 4.9: Application: isRelease() function not available ===

See [[#Slicer_4.8:_Application:_isRelease.28.29_function_not_available_or_deprecated]]

=== Slicer 4.9: slicer.util.getNode() raises exception if node not found ===

If slicer.util.getNode() is called and the node is not found then instead of just returning None (Slicer 4.8 behavior), the method now raises a MRMLNodeNotFoundException. This makes code debugging easier (the error is reported when it happens), and in general more consistent with Python conventions.

How to update existing code:

It is advisable to only use slicer.util.getNode in tests, or interactively in the Python console, as its behavior is somewhat unpredictable (it may either found a node by name or ID, and result of wildcard search is even less deterministic). In general, it is recommended to use the MRML scene's GetFirstNodeByName and GetNodeByID methods instead.

'''Replace this:'''

<pre>
n = slicer.util.getNode(nodeNameOrID)
</pre>

'''By one of these:'''

If node is to be found by name:
<pre>
n = slicer.mrmlScene.GetFirstNodeByName(nodeName)
</pre>

If node is to be found by ID:
<pre>
n = slicer.mrmlScene.GetNodeByID(nodeID)
</pre>

If node is to be found by name or ID (slower, less predictable, recommended for testing only):

<pre>
try:
n = slicer.util.getNode(nodeNameOrID)
except slicer.util.MRMLNodeNotFoundException:
n = None
</pre>

More information: https://github.com/Slicer/Slicer/commit/b63484af1b1b413f35396f8f7efb73e870448bd4

===Slicer 4.8: Application: isRelease() function not available or deprecated===

Error message similar to:

Missing/deprecated qSlicerCoreApplication::isRelease()

or

Missing/deprecated slicer.app.isRelease()

Solution:

Use <tt>qSlicerCoreApplication::releaseType() == "Stable"</tt>

Summary:

Prior to r26420, the variable <tt>Slicer_VERSION_TWEAK</tt> was used to check if a "stable release" was built. The variable value
was set by updating the sources and defining the variable to an integer greater or equal to 0. In other word, if the variable
evaluated to an empty string, a nighty or experimental build was being done, if it evaluated to an integer, a stable release build
was being done.

The approach had few issues:
* the name of the variable was confusing
* identifying a "stable release" only from a source tree revision was not enough. Indeed the environment defining a "release" is the one found on the build machines used to generate the installer.
* nightly build are also considered as release

To address this, the CMake variable <tt>Slicer_RELEASE_TYPE</tt> was introduced. As of 2017-10-04, it can be set to <tt>Experimental</tt>, <tt>Nightly</tt>
or <tt>Stable</tt> with <tt>Experimental</tt> being the value hard-coded in the source.

Identifying a build as "stable" is now explicitly done by setting <tt>Slicer_RELEASE_TYPE</tt> to <tt>Stable</tt> at configure time.

Also, since the concept of release types was introduced, the function <tt>isRelease()</tt> has been removed in favor of <tt>releaseType()</tt>.

References:

https://github.com/Slicer/Slicer/pull/354

===Slicer Python Module: modulewidget and others removed.===

 Summary
Python classes formerly in "slicer.moduledm", "slicer.modulelogic", "slicer.modulemrml"
and "slicer.modulewidget" are now directly available in the slicer module.

See example of change [https://github.com/QIICR/LongitudinalPETCT/pull/11 here].

Rational:

See comments in commit messages referenced blow.

References:

https://github.com/Slicer/Slicer/commit/628f83fe7a6f4e0710e306bcaf7c04b9e3e5e6bd

https://github.com/Slicer/Slicer/commit/9cb5668fde1abc8f0430a91ca37fc29277ceeb4e

===MRML: Slicer 4.6: Moved up vtkMRMLStorableNode in the MRML node hierarchy.===

Rational:

vtkMRMLStorableNode is not a children of vtkMRMLTransformable node anymore,
but directly a children of vtkMRMLNode.

This allows making a node storable without requiring it to be also
transformable. It is important for several node types (color maps, tables,
etc), which require separate storage node but are not transformable.

References:
* Changed introduced in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24891 r24891]

Error message similar to:

/tmp/LongitudinalPETCT/MRML/vtkMRMLLongitudinalPETCTStudyNode.cxx: In member function ‘void vtkMRMLLongitudinalPETCTStudyNode::ObserveRegistrationTransform(bool)’:
/tmp/LongitudinalPETCT/MRML/vtkMRMLLongitudinalPETCTStudyNode.cxx:478:28: error: ‘class vtkMRMLVolumePropertyNode’ has no member named ‘GetParentTransformNode’
&& propNode->GetParentTransformNode()
^
/tmp/LongitudinalPETCT/MRML/vtkMRMLLongitudinalPETCTStudyNode.cxx:480:23: error: ‘class vtkMRMLVolumePropertyNode’ has no member named ‘SetAndObserveTransformNodeID’
propNode->SetAndObserveTransformNodeID(
^
/tmp/LongitudinalPETCT/MRML/vtkMRMLLongitudinalPETCTStudyNode.cxx:503:23: error: ‘class vtkMRMLVolumePropertyNode’ has no member named ‘SetAndObserveTransformNodeID’
propNode->SetAndObserveTransformNodeID(NULL);
^

Solution:

Removes lines and/or refactor code

===MRML: Slicer 4.5: Introduction of vtkMRMLLabelMapVolumeNode===

Rational:

Before <tt>vtkMRMLScalarVolumeNode</tt> was used for both scalar and label map
volumes and the LabelMap custom MRML node attribute was used for
distinguishing between them (0=scalar; 1=label map volume).

This made conversion between labelmap/scalar volumes very easy but made
it difficult to customize behavior, display, processing of segmentation
information.

Now a new <tt>vtkMRMLLabelMapVolumeNode</tt> class is used for storing segmentation
information (still using <tt>vtkMRMLScalarVolume</tt> used as base class for backward
compatibility; but in the future the base class may be changed to reflect
that segmentation can be represented in various ways, not just as volumes).

Error message similar to:

error: ‘class vtkMRMLScalarVolumeNode’ has no member named ‘SetLabelMap’
outputVolumeNode->SetLabelMap(1);
^

Solution (part1: down cast to <tt>vtkMRMLLabelMapVolumeNode</tt>, remove call to <tt>SetLabelMap</tt>)

Replace lines like:

vtkMRMLNode* outputNode = d->OutputLabelVolumeMRMLNodeComboBox->currentNode();
vtkMRMLScalarVolumeNode* outputVolumeNode = vtkMRMLScalarVolumeNode::SafeDownCast(outputNode);
[...]
outputVolumeNode->SetLabelMap(1);

with:

vtkMRMLLabelMapVolumeNode* outputVolumeNode =
vtkMRMLLabelMapVolumeNode::SafeDownCast(d->OutputLabelVolumeMRMLNodeComboBox->currentNode());
[...]

Solution (part2: Update UI file):

Replace lines like:

<widget class="qMRMLNodeComboBox" name="InputLabelVolumeMRMLNodeComboBox">
<property name="nodeTypes">
<stringlist>
<string>vtkMRMLScalarVolumeNode</string>
</stringlist>
</property>
[...]
</widget>

with:

<widget class="qMRMLNodeComboBox" name="InputLabelVolumeMRMLNodeComboBox">
<property name="nodeTypes">
<stringlist>
<string>vtkMRMLLabelMapVolumeNode</string> <------------- Update Here
</stringlist>
</property>
[...]
</widget>

Solution (part3: Update node selector configuration):

Replace lines like:

nodeSelector.setNodeTypes(QStringList("vtkMRMLScalarVolumeNode"));
nodeSelector.addAttribute("vtkMRMLScalarVolumeNode", "LabelMap", "1");

with:

nodeSelector.setNodeTypes(QStringList("vtkMRMLLabelMapVolumeNode"));

References:
* http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/Segmentations#vtkMRMLLabelMapVolumeNode_integration
* http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24291

===CLI: Slicer 4.3: Add ITKFactoryRegistration library centralizing ITK IO factory registration===

Rational:

Linking against <tt>ITKFactoryRegistration</tt> ensures that ITK IO factory are properly registered on all supported platforms.

Error message similar to:

Undefined symbols for architecture x86_64:
"itk::itkFactoryRegistration()", referenced from:
_main in ImageMakerTest.cxx.o
ld: symbol(s) not found for architecture x86_64

Solution:

Replace lines like:

target_link_libraries(${CLP}Test ${CLP}Lib)

with:

target_link_libraries(${CLP}Test ${CLP}Lib ${SlicerExecutionModel_EXTRA_EXECUTABLE_TARGET_LIBRARIES})

References:

* http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21592
* https://issues.slicer.org/view.php?id=2813

@@ Line 328: / Line 328: @@
 <b>References:</b>
-* http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/Segmentations#vtkMRMLLabelMapVolumeNode_integration
+* http://www.slicer.org/wiki/Documentation/Labs/Segmentations#vtkMRMLLabelMapVolumeNode_integration
 * http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24291

Documentation/4.10/Developers/Tutorials/MigrationGuide/Slicer - Revision history

Grundlett: Text replacement - "slicerWiki/index.php" to "wiki"

UpdateBot: Nightly -> 4.10