Lookmarks vs. Custom Filters
The lookmark functionality in ParaView 2 is currently being replaced with "custom filters" in ParaView 3. The implementations for each are quite different. Recently while preparing for a presentation to some folks at Goodyear, Brian noted some important functionality that was available with lookmarks is missing in custom filters.
On reflection, the problem may be that lookmarks and custom filters have some subtle but important differences. A lookmark simply captures the state of all or part of a filter and restores it at some later time. In contrast, a custom filter allows users to build new filters from existing filters. It creates a new filter with a custom interface and a composite functionality.
The shift in the name of lookmarks has also lead to a shift in the implementation. This has lead to some new features (such as a custom interface that simplifies access) that while neat are maybe not all that important. Meanwhile, the current implementation has left some feature gaps that make custom filters unusable for the majority of use cases.
First, most interesting use cases will generate output from multiple filters. At the very least we need to have the ability to independently control the display of these outputs. Most of the time we need the pieces to display differently. For example, the main geometry should have a specific variable map whereas the outlines of the cells (generated by one of the internal filters) should be a solid color to make it visible. Now, there are plans to support multiple outputs in custom filters, but there are still open issues with the implementation and user interface. At the very least accessing these multiple outputs will be more cumbersome and less intuitive than accessing a single output from a filter. At worse, we might find the mechanism downright confusing and/or still missing vital features.
Second, when capturing an "operation" in ParaView, the user is usually focused on how the view is set up. When reusing the captured operation, the expectation is that the same view is restored, possible for some different input. Besides being expected, restoring the view is often necessary for the operation to be useful. Such a restore necessarily involves saving and restoring the displays. This is an operation that is outside of the domain of filters, and hence is not currently supported.
These features need to be in place. We could implement them in one of three ways: implement separate functionality for custom filters and lookmarks, add the functionality to the existing custom filters, replace custom filters with lookmarks. Each approach has its drawbacks.
I worry that if have a separate implementation for custom filters and lookmarks, it will lead to major user confusion. The problem is that the two features are very similar, so similar that it has eluded our own group on how they are different. I fear it will be unclear when each will be used.
The problem with modifying custom filters to perform all of the lookmark tasks is that we may be pounding the proverbial round peg in a square hole. We are fitting features into "custom filters" that are simply not features of most filters. The risk is that the end result may be a Frankenstein of functionality with no clear paradigm. The interface may become confusing and difficult to use. The end result may be a solution worse than either a custom filter or lookmark on its own.
Replacing custom filters with lookmarks requires us to reevaluate the use cases that custom filters have and deciding that they are not important enough to keep. The question is, how useful is it to have the encapsulation and custom interface for a group of filters?
