Skip to content

BUG: Plotting fixes

Andras Lasso requested to merge github/fork/lassoan/chart-node-fixes2 into master

just for review, not to merge it yet

  1. Added macros for reading, writing, copying, and printing MRML node properties

  2. vtkPlot was stored in vtkPlotDataNode and was used in multiple charts. This caused plots to malfunction when multiple plot views were visible (for example, reset axes did not work).

A vtkPlot cannot be used in multiple charts, as vtkPlot holds pointers to axes and charts own axes objects. Fixed it by storing only properties in vtkPlotDataNode (not a vtkPlot object), vtkPlot objects are vreated in qMRMLPlotView (based on properties stored in vtkPlotDataNode).

  1. Store vtkMRMLPlotChartNode properties in MRML node members access them using direct get/set methods, instead of using generic node attributes.

This node broke away from the MRML node convention by storing properties in custom attributes. Attributes are less easy to discover, more complicated to change (need to make sure the correct attribute name is used and value is properly converted to/from string).

  1. Instead of using "Indexes" special column value, empty string means that X axis should be value index.

Now "Indexes" is no longer a reserved column name; it can be used freely in tables.

  1. Replaced "Custom" option in plot controller widgets by invalid selection

  2. Removed modification of MRML nodes in qMRMLPlotViewControllerWidget::updateWidgetFromMRML

Problem: Common PlotData type, x column name, and marker style was stored in vtkMRMLPlotChartNode. However, this information may get out of sync with actual common properties in associated PlotData nodes. Consolidation of redundant information happened in qMRMLPlotViewControllerWidget::updateWidgetFromMRML, by modifying PlotData nodes. In general, MRML nodes must not be modified in updateWidgetFromMRML calls and data redundancy should be avoided.

Solution: Do not store redundant information in PlotChart node. Common PlotData type, x column name, and marker style is determined when needed, by looking into associated PlotData nodes. When user changes a common property on the GUI, PlotData nodes are updated immediately.

Known limitation:

  • Default plot colors are not set yet (they should be set when a new plot is created)

Merge request reports