# Drop vtkSMFieldDataDomain

**URL:** https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940
**Category:** Development
**Created:** [November 20, 2018, 7:37pm UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940 "2018-11-20T19:37:12Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![utkarsh.ayachit](https://discourse.paraview.org/user_avatar/discourse.paraview.org/utkarsh.ayachit/32/39_2.png) [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [November 20, 2018, 7:37pm UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940/1 "2018-11-20T19:37:12Z")

</div>

I am working on fixing [issue #18621](https://gitlab.kitware.com/paraview/paraview/issues/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?

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [November 21, 2018, 9:22am UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940/2 "2018-11-21T09:22:17Z")

</div>

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

---

<div class="post-metadata">

### Author: ![utkarsh.ayachit](https://discourse.paraview.org/user_avatar/discourse.paraview.org/utkarsh.ayachit/32/39_2.png) [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [November 21, 2018, 1:59pm UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940/3 "2018-11-21T13:59:02Z")

</div>

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!

---

<div class="post-metadata">

### Author: ![utkarsh.ayachit](https://discourse.paraview.org/user_avatar/discourse.paraview.org/utkarsh.ayachit/32/39_2.png) [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [November 21, 2018, 8:11pm UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940/4 "2018-11-21T20:11:55Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![utkarsh.ayachit](https://discourse.paraview.org/user_avatar/discourse.paraview.org/utkarsh.ayachit/32/39_2.png) [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [November 23, 2018, 12:01am UTC](https://discourse.paraview.org/t/drop-vtksmfielddatadomain/940/5 "2018-11-23T00:01:33Z")

</div>

I have a fix underway here: [https://gitlab.kitware.com/paraview/paraview/merge\_requests/2902](https://gitlab.kitware.com/paraview/paraview/merge_requests/2902)
