Baby-Proofing ServerManager

• Difficulty accessing data on client side
  • Why do I need a representation to deliver data? I want data damn it! Give it to me!
  • UpdateVTKObjects() / UpdateInformation() / UpdatePipeline() / Representation::Update() what crap are you talking about? Just give me my data!
  • Maybe all we need is a vtkSMSourceProxy::GetData() method which internally can do whatever crap it wants to do with representations etc.
  • Ideally it seems that the view should have access to the QWidget and the representation should have the pipeline connection, and it can do what it wants.
  • Undo/redo and serialization should be optional for views/representations, so that a proxy layer is not required.
• Views and Representations
  • Everything should be VTK Views and Representations. We need to design how VTK Views and Representations can work in Client-Server/Compositing modes. Having subclasses beyond the core proxy classes i.e. vtkSMProxy, vtkSMSourceProxy, vtkSMWriterProxy, vtkSMViewProxy, vtkSMRepresentationProxy means we have screwed up.
• Simple XML
  • It must be possible to auto-generate xmls using some minimal annotation if needed. We need not actually implement auto-generation wizard, but it should be easily doable. If the user has to think at all when writing XMLs, then we have messed up.
  • Should we use introspection to automatically make XML, or even use that by default without XML?
• Domains
  • Domains are the one reason why writing xmls are complicated. It really hard to set up domains so that complicated properties such as array selection, block selection work. Any domain that has a “RequiredProperty” is just too complicated! “This has to update, then only the data-array are valid, argh no, that is not updated –aaaah!” – the common grievance. This should just not happen. Don’t know how we fix this, but we need to fix this.
  • UpdateDependentDomains() and all that stuff further complicates domains. They need to be updated, when do update them? Did I update already? Do I need to update? – just too much complication.
• Default Property Values
  • Properties need sensible default values, and these are not always determinable at compile time. Many a times the VTK-object is more capable to picking a default value – how can we make that work?
• Building pipelines
  • Building/executing pipelines with proxies should be as easy (or easier) in server manager as it is in VTK. The API should perhaps also be made very consistent (exactly consistent?) with how things are done in VTK. The fact that what is called "algorithm" or "filter" in VTK is called "source" in ParaView is confusing.
• Accessing properties
  • vtkSMPropertyHelper/pqPropertyHelper make life easier for getting/setting proxy properties. Could this functionality or something like it be put right into the proxy superclass with short function names?

Actions

• Add special comments/macros for marking up header files to make properties.

vtkSMProperty(Foobar, SetFoobar, GetFoobar, "Documentation string", min=0, max=1);

This could make automatic XML generation, hence programmers don't need to learn XML.

• Add some functionality to vtkView to make it play nicer with ParaView (undo/redo, state, etc.). Make vtkDataRepresentation also have methods for time/piece, etc.

• Make a vtkAlgorithm subclass that contains a source proxy and makes it look like an algorithm (collects and moves to client). Allows mixing ParaView and VTK pipelines. May be too complex.

• To do serialization:
  • Integrate into vtkObject
  • Make proxy subclass
  • Make serialization helper

• Would be ideal to have panels (e.g. for charts) that work in ParaView and could work in other applications. Undo/redo support for ParaView should be separate.

For VTK: panel -> (signals) -> vtkObject

For ParaView: panel -> (signals) -> proxy with undo/redo, state -> (signals) -> vtkObject