Drop vtkSMFieldDataDomain


(Utkarsh Ayachit) #1

I am working on fixing issue #18621. As I was looking at related things, it occurred to me that vtkSMFieldDataDomain is pretty much not necessary anymore. I cannot see of any use-case that’s not already covered by simply adding the vtkSMArrayListDomain to the property. Is there anything I am missing? Can anyone think of any use-cases where the vtkSMFieldDataDomain is actually useful?


(Mathieu Westphal) #2

I always thought it was responsible for adding the small point/cell/field icon in the combo box alongside ArrayListDomain.


(Utkarsh Ayachit) #3

it is currently, but really not necessary. all that information can be gather from vtkSMArrayListDomain itself. I suspect the original intent was to control whether field type selection was supported at all but now vtkSMArrayListDomain together with its input array domain correctly support the use cases where only specific field types are supported.

I am going to put vtkSMFieldDataType on the chopping block. thanks for responding!


(Utkarsh Ayachit) #4

found the case where it’s needed. There’s no need to use it on a vtkSMStringVectorProperty which already has a vtkSMArrayListDomain. It’s only needed for a vtkSMIntVectorProperty that is intended to allow the user to choose the attribute type alone without the associated array. For example, on the SpreadsheetView proxy, we want to select if the view is showing cell data or point data etc.


(Utkarsh Ayachit) #5

I have a fix underway here: https://gitlab.kitware.com/paraview/paraview/merge_requests/2902