ParaView 5.10.0 RC1 Show/Hide Icon Missing

In 5.10.0-RC1 (Windows MPI exe) I’ve found that when I add a filter via the Python Shell the visibility icon is initially not shown at all.

Clip() produces:

image

If I click in that void or use Show() it then appears.

image

In 5.9 the icon would be immediately shown in the “not visible” state

image

(minor) Bug?.

Works correctly for me. Here is what I did:

  • MacOS, 5.10.0-RC1 (and 5.9.1 as a baseline), builtin server.
  • In a View/ Python View
  • sphere=Sphere()
  • Show()
  • Render()
  • clip=Clip()

The grayed out eyeball is on the clip.

Does this work? Please give us really specific directions how to replicate…

Steps to reproduce:

  • Load can.ex2 and hit ‘Apply’
  • clip=Clip() in Python Shell

Yep, replicated. I bet it’s the new Exodus reader - the IOSS reader.

https://gitlab.kitware.com/paraview/paraview/-/issues/21041

Thanks for reporting.
Alan

Hi Theodore,

This is a side effect of how things are done in ParaView and has been the behavior for a long time. When you create a Clip() filter, that only creates the filter. Upon creation, the filter is registered with ParaView, hence it shows up in the pipeline browser. However, in the active view, no representation for the filter has yet been created in your script. Show() does that. Since there is no representation, there is no visibility icon. Once Show() is called, a representation exists and you get the visibility icon.

It might be possible to show a visibility icon when no representation exists and call the equivalent of Show() when it is set to be visible. @utkarsh.ayachit - thoughts?

I just tested again with the can.ex2 file on 5.9.0 and it DOES show the visibility icon as soon as the clip is created, so the behavior is different in 5.10 now.

My original examples (screenshots in the first post) were using the XDMF reader, so the issue is not isolated to the IOSS reader. But I just tested with the example sources “headsq.vti” and “rectinlinearGrid.pvd” as well and the issue does NOT appear, so it is only an issue with some readers.
Do the XDFM and IOSS readers inherit the same abstract class?

Sorry Cory, this is a regression from 5.9.1 to 5.10.0-RC1. I posted screenshots in the bug post.