ParaQ:API
Overview
We need to establish the architecture for how the GUI code interacts with the Server Manager.
Goals
The goals of designing this architecture are:
- Establish a general method for how the GUI talks to the Server Manager.
- Provide a way for the GUI to update correctly if a scripting client is modifying the server.
- Be designed to minimize traffic with the server.
- Decouple GUI from Server Manager to allow using of Qt Designer.
- To provide functionality such that multiple inheritance of VTK & Qt objects is not necessary (toolkits have different object management schemes).
- Allow GUI to control behavior. Meaning, Server Manager or API doesn't impose behavior on the GUI.
Use Cases
 Use Case 1: Use case of API linking SM properties with Qt properties. Object controller controls behavior of GUI panel (vtkSphereSource). GUI panel could be generated or designed. API takes properties to set in bulk to minimize possible network traffic. |
 Use Case 2: Use case of a pipeline inspector/browser. API provides GUI with events for proxy creation. API also provides GUI with events for input/output connections between proxies. GUI calls SM directly to manipulate the pipeline. |
 Use Case 3: Use case of linked views. Can linked views be thought of as linked properties and a view watching for property changes? |
Use Case 3 (Histogram): |
The SM API
The Server Manager API contains these basic components:
- Proxy
- Property
- Domain
- Data
The Qt-SM API
The Qt interface to SM for the GUI will have functions like the following (this is not set in stone yet).
{
signals:
// signal from SM that a proxy was created
void ProxyCreated(vtkSMProxy* Proxy);
// signal from SM that a proxy was deleted
void ProxyDeleted(vtkSMProxy* Proxy);
// signal from SM that a proxy has an added input
void ProxyInputAdded(vtkSMProxy* Proxy, vtkSMProxy* Input);
// signal from SM that a proxy has a removed input
void ProxyInputRemoved(vtkSMProxy* Proxy, vtkSMProxy* Input);
// signal from SM that a proxy has an added output
void ProxyOutputAdded(vtkSMProxy* Proxy, vtkSMProxy* Output);
// signal from SM that a proxy has a removed output
void ProxyOutputRemoved(vtkSMProxy* Proxy, vtkSMProxy* Output);
public:
// Set the specified property of a proxy
// property index 0 is assumed if Value is not a QList
void SetProperty(vtkSMProperty*, QVariant);
// Get the specified property of a proxy
// if property has more than one element, a QList is returned
QVariant GetProperty(vtkSMProperty*);
// Set the specified property of a proxy
void SetProperty(vtkSMProperty* Property, int Index, QVariant Value);
// Get the specified property of a proxy
QVariant GetProperty(vtkSMProperty* Property, int Index);
// Property linking
// If a vtkSMProperty is linked to multiple QObjects' properties, this API
// will query the Server Manager once for the data and give it to all QObjects.
// Link a property of a proxy to a property of a QObject.
// The QObject property follows the vtkSMProperty.
void LinkPropertyTo(vtkSMProxy* Proxy, vtkSMProperty* Property, int Index,
QObject* qObject, const char* qProperty);
// Unlink a property of a proxy from a property of a QObject.
void UnlinkPropertyFrom(vtkSMProxy* Proxy, vtkSMProperty* Property, int Index,
QObject* qObject, const char* qProperty);
// Link a property of a QObject to a property of a proxy.
// The vtkSMProperty follows the QObject's property.
void LinkPropertyTo(QObject* qObject, const char* qProperty,
vtkSMProxy* Proxy, vtkSMProperty* Property, int Index);
// Unlink a property of a QObject from a property of a proxy.
void UnlinkPropertyFrom(QObject* qObject, const char* qProperty,
vtkSMProxy* Proxy, vtkSMProperty* Property, int Index);
// Domain linking
// link a vtkSMDomain to a QObject's property.
// The QObject property must be of type QList<QString>, QList<int>, or QList<QList<int>>.
// TODO - enforce compile time type checking?
void LinkDomain(vtkSMDomain* Domain, QObject* qObject, const char* qProperty);
// unlink a vtkSMDomain from a QObject's property.
// The QObject property must be of type QList<QString>, QList<int>, or QList<QList<int>>.
void UnLinkDomain(vtkSMDomain* Domain, QObject* qObject, const char* qProperty);
}
3D Widgets
????????????????????
We're not sure that we know enough about these animals to see how they fit in the API.
We did discuss about a case as follows:
A 3D widget is associated with a vtkCutter. Suppose a vtkCutter is embedded in the middle of a compound filter. Is the 3d widget part of the pipeline or not? Is it only part of the pipeline if a property that the 3d widget can change is exposed by the compound filter?
Linked Views
One proposal for achieving linked views in ParaQ is to link vtk properties through the Server Manager. Any two vtk properties with a similar type and range could be linked. This would allow for the following use cases:
- Two or more sphere sources have linked radius properties
- Two or more camera to have linked orientation
- Linked selection between multiple views by linking Cell List between multiple vtkExtractCells
- Linked cut planes in multiple views by linking the normal and origin of the vtkPlane provided to a vtkExtractGeometry
These use cases are just an example of what could be accomplished. The main question is whether or not this approach will work for all of the linked use cases that are needed.
Special Note: When linking properties, special care must be taken to avoid circular linking.
The Qt to SM API assumes that the above linking method in used and that the Link object is a proxy. This would allow the existing signals for proxy creation and proxy connections to be used.
Compound Filters
Compound filters will be implemented as proxy/sub-proxies. Exposed properties will be properties of the proxy. So as far as the Qt-SM API is concerned, these proxies look like any other proxies.
