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
VisTrails

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?"

Suggestions for different pipeline/object selection/views (by Berk)

I have been thinking about pipeline/object browsers for a while. This morning, I had a chat with Charles, Ken and Andy about pipeline browsers also. A few things we all agree on:

• Tree-like views of pipeline are complicated and confusing, specially when the pipeline contains more than one or two connections. For example, let's say we have the following pipeline: sphere -> clip -> isoline -> tube -> shrink. This is a simple pipeline but a tree representation of it is already 5 deep. In this representation, the user would have to uncollapse 4 groups to get to the last (or first) object in the pipeline. This gets even more complicated if the browser is to include non-pipeline objects like color maps. Also, what node is the root node? The producer or the consumer?
• (Mini) pipeline browser is nice but rarely used.
• We like the flat list view. The issue with this view is that it does not provide any information about connectivity and what the objects in the list are. There are a few ways of improving this:
  • Allowing user to pick objects on the 3D window. Most users are used to selecting a object and then making changes to it. There are many application that follow this model: word processors, image editors etc etc...
  • Highlighting the picked object on the 3D window.
  • Color coding the items on the list based on the currently selected object. For example, all inputs could be colored green, outputs blue, related/contained objects brown.
  • A filter's input can be part of the default name assigned to it like : Tube1 (applied to isoline)
  • Allowing the user to sort the items on the list based on a few properties.
  • It is possible to implement drag & drop to change pipeline. The user could drag a filter and drop it on a source to change the input. If the filter has multiple inputs and the selection of input is ambigious, a selection dialog can be shown. Invalid inputs can be marked by changing the cursor. This should not be the only way of changing inputs. An input property in the inspector is easier to understand.
• The "flat" view does not have to be that flat. It can be hierarchical do show blocks/parts. This would allow users to turn on/off visibility of blocks, select them etc etc...