I was playing around with the Probe Location filter and noticed that it’s not available if the dataset has no field data. At first I didn’t realize why the Probe Location filter wasn’t available which was a bit frustrating. I’m also thinking that the Probe Location filter may be useful when there’s no field data available just to get the location of certain parts of the dataset.
So with that said, does it make sense to others to change the Probe Location filter to not have the restriction of requiring field data in order to be available?
You could use the Point Source for this purpose if you just want to be able to grab the crosshairs widget and see its XYZ position update as you move around.
Yes, I was also curious about the use case of using the probe filter when there are no fields to probe. The only thing the probe filter provides is the vtkValidPointMask. I guess that could be useful, but I’ve never seen an example.
Getting into the full details of how this came up: I was working with another user who was showing me some data and as he was working through his process I suggested that maybe the Probe Location filter would be useful for what he was doing. When he tried to access the Probe Location filter it was grayed out and since I didn’t have the data and this discussion with him was over a remote video call it was a bit tough to diagnose the issue. It just seems like getting rid of the field requirement is a slight improvement for users that may not be aware of why the filter is grayed out. It’s certainly not a huge deal but seemed like an unneeded barrier to the filter.
I guess I’m ambivalent about whether removing the array requirement is good or not. It seems unintuitive to me to attach a filter to a dataset to get location info rather than some kind of source.
Thinking a bit more about giving PV users GUI feedback on why some filters are available and others are not, maybe the a better and more general way would to allow some type of hover ability for filters that are currently unavailable/greyed out (e.g. requires a polydata input but the current grid is not a polydata). Since it seems like there’s a small set of cases explicitly defined in the filter’s XML on when a filter should be available maybe this is a better general solution to have the hover help automatically generated form the filter’s XML information.
Do people think this is a better long-term solution?
On Windows (and maybe linux) we do provide a message in the status bar on why a filter is grayed out. It might not be the first place one would look for such a message, so I can understand it being missed. It also doesn’t work on macOS for some reason.
If technically possible, it might be better to put up a tooltip near the menu item. I’m not sure it is possible, but worth considering.