No-Apply Mechanism for Creating Pipelines

The Problem

When creating visualization pipelines in ParaView, the GUI forces the user to hit "Apply" at every stage in the pipeline before another pipeline stage can be added. Thus to create a simple pipeline such as Reader -> Cut, the user has to create the Reader (or open the data file), then hit Apply, then create the Cut filter and hit Apply again. There are a few problems with this approach:

• The intermediate results are rendered. Even if the sphere had no interest in the output of the reader, he has to wait to see the generated rendering. This is not a huge problem since for really large datasets (based on the settings), this generally leads to rendering only a wireframe.
• The pipeline is not truly demand driven i.e. the reader, since it has no clue what pipelines may be connected, generally ends up reading the full dataset during the first Apply. Even if the Cut filter has means to tell what bounds it's interested in, that information is not available during the first Apply and hence the reader simply has to read everything.

The goal of this proposal is make it possible for the user to build pipelines without having to hit "Apply" or cause execution on the intermediate filters while creating the pipeline.

The Difficulty

Enabling application of filters that don't require use to choose arrays is trivial (that's to the recent cleanup in the ServerManager code that made things called OutputPorts less precarious than before). In fact following some minor tweaks, we can easily enable filters such as Clip (not w/ scalar), Cut, Shrink working. The problem comes with filters that want the user to choose arrays. Without having executed the filter/reader, how does the GUI get information about array available? We can ignore the ranges: we ensure that all user interface components where user puts values in a range, the user is able to enter values beyond the current range, and that pretty much solves our problem (this is mostly the case already, to handle the case where ranges change over time, however some filters e.g. Extract VOI seem to have minor issues). But we need the array names/number of components information.

One could say, if the information is not available, we just let the user enter the array names in a text-box, but that would be very cumbersome to use. Even though the user may know the arrays to expect, they can generally be named in a non-human-friendly form, prone to typos and misspellings.

Also note that some filters may generate new arrays of a known name e.g. Elevation, while others may generate new array whose name depends on a property of the filter itself, e.g. Calculator, and still others may generate new arrays based on input arrays/arraynames as well as properties on the filter eg. point-data-to-cell-data, cell derivatives. All these cases need to be handled gracefully otherwise we will run into usability issues that would be hard to overlook.