Properties, property groups and dependencies

Development
1

For a filter, I need the following input properties:

Value1, a value name from a list of strings - “<none>” by default
Min1, Max1 and Steps1, for some loop.

Requirements and dependencies:

a) Min1, Max1 and Steps1 should only be active if Value1 is not “<none>”
b) Steps1 must be positive (minimum 1)
c) Max1 must be larger than Min1 (and also the other way round, of course)

Furthermore:

Value2, a second value name from the same list of strings - “<none>” by default
Min2, Max2 and Steps2, for a second loop.

Requirements and dependencies for this last group are same as above, thus a), b) and c), plus the following:

d) Value2 is only active if Value1 is not “<none>”

On top of that, I want some graphical display in the properties panel that visualizes the current choice of the user. Of course this display would depend on all the above properties.

For me the easiest to implement would be to just write some custom property widget for all the above properties that fulfills all the above requirements and dependencies, plus provides the graphical display.

A more “Paraview like” solution would be to go for a more generic solution, like the following - but there I have some problems to see how to achieve this!

  • a) and d) For these I would need some kind of decorator that activates other properties if one does not have a certain value: Maybe I would somehow find a way to achieve this, looking at examples within the Paraview code.
  • b) can be achieved with an IntRangeDomain, if I provide not only the minimum value (1), but also some reasonable maximum
  • c) is in a way realized for the Threshold filter, but in a way that it looks like I still cannot use it: It assumes that the values are attributes, and a value range is specified by that attribute - which is not my use case! I only need to ensure max>min
  • The visualization could be realized by some “visualize only” property widget - if only I knew how to attach it to the other properties in such a way that it is triggered if they change, but without a way to change the properties through this property widget. I might have to specify some dummy information_only property and attach it to that property widget

What would Paraview experts who know very well the logic of these plugin XML files do for this problem?

For me it would be the fastest if I just write a custom property widget with the means of Qt. On the other hand would I still be keen to better understand the Paraview plugin XML logic and all the nice things that you can do with it!

2

a) Min1, Max1 and Steps1 should only be active if Value1 is not “”

This is easily supported with pqGenericPropertyWidgetDecorator. It already supports inverse attribute which can be used for such not-equivalent checks.

b) Steps1 must be positive (minimum 1)

You’ll need a custom widget or decorator for this. All domains in ParaVIew are only “hints” and never enforce the value. Even if you specify min and max for IntRangeDomain, for example, you can always enter a value outside the range.

c) Max1 must be larger than Min1 (and also the other way round, of course)

A custom widget that uses a double-ended slider would really be nice. I don’t think we ever added that back to ParaView.

For me it would be the fastest if I just write a custom property widget with the means of Qt. On the other hand would I still be keen to better understand the Paraview plugin XML logic and all the nice things that you can do with it!

ParaView’s XML is not intended to address every combination. In fact, putting together custom widgets is indeed something that is fairly consistent with ParaView design. Be wary of doing too much in the customized widgets code, though. Keeping the code as simple as possible as always a good idea.

3

Thanks a lot Utkarsh for these explanations!

With the means of Qt indeed “everything” is always possible! Implicitly meaning that going this way is finally often the most straightforward solution for a problem.

Still, reading the ParaView code is often a welcome learning for me - up to the point when things are so much entangled between cxx and xml code that my brain is not any more able to keep the entire picture together… And “half understanding” is often far worse than not understanding at all: It keeps you busy, but still does not guide you to a good solution :wink:

4

That’s fair! And you’re right, it’s definitely better if you can avoid Qt code since that just keeps your application more portable across versions. That, however, does imply some flexibility in the requirements. For example, if you’re okay with UI not strictly enforcing the limits, but making the underlying code robust to handle values outside valid ranges, then XML-alone would work.