PipelineBrowser

Overview

The following is a gathering of requirements and comparison with other applications to help decide how to present management of the VTK pipeline in the GUI. The GUI developers don't yet know which presentation method to use. We'd like feedback and direction on which way to do it.

Requirements

• support multiple pipelines
• not take up too much screen real estate
• clear representation of connections
• clear representation of pipelines objects with multiview and histogram
• create, edit and manage pipeline
• support 3d widgets
• support property linking
• support macros
• Suggested: display subsets of visualization graph.

Other Applications

opendx
SCIRun
VTK Designer
MayaVi

Idea 1

Have a workspace for manipulating pipeline similar to SCIRun and VTK Designer. This takes up a good amount of screen space. An issue with this way, although it is really cool, is that it easily divides users. You'll get some who love it, and some who hate it, but not much in between.

Idea 2 (most similar to current ParaView)

Use a table for managing linked properties. Use Object Inspector to handle multiviews, where it provides a combo box of which view to put the object in. Use Object Inspector to manage connections. Provide a read-only graphical & compact view of the pipeline to satisfy other requirements not met already. It may not be as clear as idea 1 when it comes to understanding the pipeline.

Idea 3

Same as Idea 2 but use a Tree View (as MayaVi) instead of a graphical representation. A tree view may seriously lack in presenting a clear picture of the pipeline connections.

Idea 4

The problem with a Tree View is that it can't represent a node with multiple input connections. K-3D, which doesn't have a full-blown pipeline browser yet, uses a "Node History" panel which displays a node, plus a hierarchical tree of all of its inputs, using a Tree View. Pros: easy to implement, it can handle multiple inputs, and it allows the user to focus on a single node and its dependencies, without having to deal with the (potentially very complex) entire visualization tree. Cons: data flow is (non-intuitively) bottom-to-top.

In the following example, "Sphere 2" is dependent upon (has incoming connections from) "Move Sphere 2" and "Sphere", while "Sphere" has an incoming connection from "Move Sphere" ...

More??

Any other ideas?

Idea N

The pipeline browser is a tabbed widget, with each tab showing the pipeline in a different representation (one of the ideas listed above). This, of course, is the correct solution as it allows the user to pick his/her favorite pipeline browser (and alleviates the love it/hate it problem). It also allows users to choose a browser based on the current task if desired, giving us the best of all worlds.

Thus, the question is not "which idea should be implemented?" but rather "which idea should be implemented first?"