How to handle the new parameter node wrapper?

Development
1

Hi @lassoan, @pieper, @jcfr, @devs,

I am in the process of porting some modules of SlicerVMTK to the new parameter node wrapper. A sample port is available in this branch.

I am requesting advice about handling things basically and in complicated cases.

  1. In the QuickArterySegmentation module of the above branch, I made the parameter node available in the logic class since it is generated by the logic class itself. The parameter node references input objects that are mapped by the wrapper to UI elements in the widget class, and also output objects that appear in the views but not as module widget elements. I wish to know if this is an acceptable way to do things.

The described approach implies also that during Python scripting, all input and output nodes must be directly get/set using the parameter node referenced in the logic class.

Otherwise, the input/output elements will have to be declared as members of the logic class and accessed directly or through accessor functions, or passed as parameters to functions of the logic class.

  1. A member of the *ParameterNode class must be declared with a known data type. Python does not seem to have a variant data type. This is a problem for a qMRMLNodeComboBox that can accept many vtkMRMLNode derived classes. I didn’t find any solution for this and see it as a limitation of the new parameter node design. Please advise about this.

  2. The *ParameterNode class does not handle some widgets, like ctkSliders* (used very often), qMRMLSpinBox and qMRMLSegmentSelectorWidget. This is another limitation that would probably be fixed when possible.

Considering these limitations, it may not be possible to always use the new parameter node wrapper. A mix up of the old and the new handling methods would have to be done, which would put the new design in question.

Regarding SlicerVMTK, the port is relatively trivial for StenosisMeasurement1D, StenosisMeasurement2D, QuickArterySegmentation and GuidedArterySegmentation modules. For CrossSectionAnalysis and ExtractCenterline, it’s a headache. As for ExtractCenterline, I did not find a compelling need for any change.

Thank you for any comment.

Regards.

2

Thanks for investigating this. I haven’t used hte ParameterNodeWrapper approach myself so I can’t advise in detail. My understanding is that it does have a limited initial feature set and that not all use cases would be a good fit for it. Others who know the code base should chime in on how good a fit the parameter node wrappers are for vmtk.

3

Thank you for your reply, I know thence where to stop expecting.

I still wish to know if the usage described in #1 is acceptable. Anyone?

4

Hi!

  1. Yes, absolutely.

  2. The variant datatype you will want to use here is typing.Union . We need to expand the documentation on this, but an example-ish can be found here: Slicer/Base/Python/slicer/tests/test_slicer_parameter_node_wrapper_gui_creation.py at 5199545b8b17cee46c801137298087a823e54ca7 · Slicer/Slicer · GitHub

  3. We are working on adding missing widgets, see this issue: Parameter node wrapper GUI connectors are missing for many widgets · Issue #7308 · Slicer/Slicer · GitHub

1 Like
5

Thank you @Sam_Horvath , I know better now how to move forward.