SMObserver Abstraction

This document describes the design for the refactoring of the GUI to become a first class observer of the Server Manager.

Overview

We are speaking about the pipeline creation/edition functionality for this document and not Accept/Reset. The ParaQ GUI has a dual role

• It reflects the current state of the Server Manager.
• It provides the user means to affect the current state of the Server Manager.

The former is critical to facilitate multiple clients/embeded python client configurations.

General guidelines to ensure that both these goals are met is:

• GUI elements directly reflect Server Manager state.
• And modification, such are creation of a proxy/deletion , connection etc are done directly on the Server Manager objects. No special handling should be done to reflect the change on the GUI, the GUI should simply get updated since the Server Manager changed.
• Remember: if it ain't registered with the Proxy Manager, it does not exist (as far as the GUI is concerned)!

I had some thoughts on class names after our phone conversation. We (eti) thought we should avoid using 'Model' in a gui class name to avoid confusion with a Qt model class. That's where the pqPipelineData class name came from. It held the proxy and connectivity data. Maybe we can change pgServerManagerModel to pqPipelineData, and rename the current pqPipelineData to something like pqPipelineObserver. --Mark Richardson 14:55, 15 May 2006 (EDT)

Application Core

Here are a few core classes and their role in the framework. Where ever applicable, we have references to previous implementation.

pqPipelineData

• This is a downgraded version of the previous pqPipelineData.
• ROLE: it simply observes the Server Manager. (may be, this class should be renamed pqServerManagerObserver).
• FUNCTIONING: Observer sever manager, process module events, filters them and fires Qt signals with necessary information.
• It has no public API except signals fired to indicate Server Manager state changes such as:;
  • source/filter/compound proxy registered/unregistered (currently separate signals are raised for each, I am not sure if that buys us anything.)
  • connection created/closed.
  • render module(or view, if you will) registered/unregistered.

pqServerManagerModel

• pqServerManagerModel is the model for the Server Manager. All the pipelines in the Server Manager need a GUI representation to obtain additional information about them such as connections, display proxies etc etc. This class collects that. This is merely representation of all the information available in the Server Manager in a more GUI friendly way.
• ROLE: Monitor Server Manager changes and create a representation for the pipelines built on the proxy manager.
• FUNCTIONING: This class connects to signals fired by pqPipelineData, and maintains a model for the Server Manager pipeline states (by state, we mean the connections not actual property values). The state is maintained by creating pqPipelineModelItem subclass objects (name is again surving from previous version, we can change it). pqServer is created for every connection made,

pqPipelineSource abstracts a proxy while a pqPipelineFilter represents a filter proxy (I am not convinced this distinction buy us anything, but letting it be for now). pqRenderModule represent a render module. pqServerManagerModel builds up a graph of several instances of these item objects, with connections among connected filters/sources/display etc etc. These item objects are self maintaining, i.e. as the server manager connnections change, they change to reflect the current SM state. The GUI can simply query a pqPipelineFilter object to get the inputs currently connected to it, it's outputs, displays etc etc. As these items are created/changed, the pqServerManagerModel fires signals with the item objects are arguments, providing a mechanism for the GUI to respond to such changes.

• pqServerManagerModel does not support any methods to create pipelines. To keep the role and implementation of this class simple, all the creation code has gone into pqPipelineBuilder.

pqPipelineBuilder

• ROLE: Builds pipelines.
• FUNCTIONING: This is a class that can build pipelines. Use this class to create sources/filters/readers etc etc. This class will ensure that all ServerManager creation checklist is met: Display proxies are created for each created source/filter/reader automatically. This class must be used to set up source/sink connections as well as breaking them. Since it manages the UndoStack, every operation is recorded as an undoable state.

pqRenderWindowManager

• This class is still loosely defined. It's general purpose is to trigger creation and connection of render modules to QVTKWigets as new frames are added. Eventually, as new render modules are registered (say by the python client), this class will create QVTKWidgets for it and so on.

pqApplicationCore

• All the classes we discussed until now form the core. The are needed to attain the two goals we mentioned earlier irrespective of how the GUI is structured. Hence, we collect them in a Singleton

pqApplicationCore. This class also ensures that the core objects are created in the right order and that signal/slot connections among core objects are set up correctly.

• Also provides centralized access to all the core class instances.
• Additionally, this class defines what we call ActiveServer/'ActiveSource/ActiveRenderModule. Typically when a new filter is created, it is connected to the ActiveSource, when a new source is created, it is created on the ActiveServer. How the active server is decided, depend on the GUI---may be by selecting it in the pipeline browser interface or whatever, this class doesn't care. It just maintains the active one.
• The functionality implemented by this class itself should be kept minimal. It should typically use delegates to do all the work. This class is merely the toolbox to look for anything of interest.

GUI

• Now the GUI code should ideally be the toolbars/button etc etc that simply requests some operation on the Core classes.

Pipeline Browser

• This GUI component requires a special mention since most of the functionality we discussed earlier is extracted from the Pipeline Browser component.
• pqPipelineModel now is the QAbtractItemModel subclass needed to connect to the tree-like view. The view queries this class to know how to build the representation. pqPipelineModel build hierarchical tables

using Server Manager model maintained by the Application Core to dictate how the view looks. It does not provide any operations such as change connections, delete etc etc. Its role is to take the pipeline state as maintained by the pqServerManagerModel and represent it in the tree-like view.

pqMainWindow

• The main window code also cleans up to simply call appropriate methods/slots with appropriate arguments on the the Core classes.
• It should have code only to maintain the GUI such as menus etc etc, with no advanced server manager knowledge.