Where's The State?

Overview

As the ParaView3 graphical user interface matures, we are beginning to encounter situations where decisions have to be made on where state is stored and whether it should be persistent or not. Some current cases:

Value List Widget

The Value List Widget redesign used by the Contour and Cut filters incorporates a new feature: the ability to turn individual values on-or-off, without having to painstakingly delete them from the list, then add them back. In the current implementation, the Contour and Cut filters each simply maintain a list of values. The UI could implement the on/off feature by maintaining a copy of the complete list, and adding/removing values on the individual filters to represent the "visible" list of values. However, this means that the on/off state will be lost when a session ends.

Recommendation: add new properties to the Contour and Cut filters to store the on/off state of each value. That way, the state is automatically serialized with the rest of the server-side state. As a special-case, the Contour and Cut filters can be coded to assume that all values are "on" if the on/off state is empty, for backwards-compatibility.

3D Widget Visibility

The Clip and Cut filter user interface panels allow the user to turn the visibility of 3D widgets on-or-off. Currently, 3D widgets are created by the user interface layer on an as-needed basis, and instances of a 3D widget are shared between panels (and thus filters). The user interface panels maintain the on/off state of the 3D widget internally, so the state remains consistent during a session but - once again - this state is lost when the session ends.

Recommendation: stop sharing 3D widgets between filters, creating one-per-filter (where required, of course) and serializing them with the rest of the session. The on/off state would automatically be serialized with the rest of the session data. This approach does imply an additional feature - some kind of "link" property that would associate a 3D widget with the filter it is used with, so the user interface layer can interact with the correct 3D widget when the user is modifying its filter. An added benefit of the persistent-3D-widget approach is that 3D widgets would be accessible to the Python client for modification.

Charts and Graphs

The ParaView3 user interface will allow users to customize charts and graphs with their choice of colors, line widths and styles, fonts, etc. This type of detailed style state must not be lost between sessions, since recreating it every time a session is re-loaded would be impractical.

Recommendation: develop a server-side graph object, that stores graph style data only. This object would be connected to a graph probe filter (or might be part of the probe filter itself), but would not be responsible for rendering graphs. This object solves two thorny problems at once: it allows graph style state to be serialized with the session automatically, and it provides a "handle" to a graph probe filter that the user interface layer can use to create a graph window when a session is loaded. Clients would have carte blanche to utilize the data provided by the server-side-graph or not, as they choose - the ParaView3 client might use pqGraph for display, or it might display data in a spreadsheet or other view. A Python client might ignore the style information and process the graph data directly, or pass it to another graphing package such as GNUPlot. A future graph-mapper object could be connected to the server-side-graph to do complete server-side rendering of a graph for the powerwall or larger-than-display-size animation.