OverView Plugins

Overview

After an extended period of external development, the Titan team is now beginning to integrate infovis components into the mainstream (VTK). Along the same lines, we would like to convert our internal client-server infovis prototype into a widely-available, parallel infovis application, tentatively titled "OverView". This document addresses some of the issues - particularly plugin-related issues - surrounding our goal of building a parallel infovis application atop ParaView.

In particular, we propose that "OverView" be implemented as "ParaView plus plugins" ... in the early stages, this would mean that we would simply be adding a new set of sources, filters, and sinks to ParaView, that could be used in the obvious ways. For example, there might be a "database reader" that produces a graph, a BFS filter that appends data to the graph, and a "graph view" that provides specialized controls and rendering for graphs. Users could instantiate pipelines in the usual ways, but with a wider set of data structures and views than before. This, in-and-of-itself, would go a long way towards realizing our goal of providing a marriage between scivis and infovis. This would also provide an excellent platform for infovis development ... algorithm designers could quickly write and deplay algorithms as plugins, testing them using the full flexibility of the ParaView pipeline.

At the same time, we realize that the ParaView user interface will be inappropriate for many infovis practitioners. For someone who just wants to load and display a graph, the many scivis-specific features of ParaView (think "isosurface button") will be an unacceptable distraction. For this reason, we need to be able to customize the user interface while trying to minimize development overhead and long-term maintenance costs. Based on our current experience, a separate client imposes too heavy a burden, particularly when what we want to do is mainly "subtracting" features from the ParaView UI. As a middle-ground, we are proposing a new type of client plugin, an "event loop" plugin, that can be used to provide a custom user interface.

Current Progress

Currently, we have begun using ParaView client and server plugins in our infovis prototype. Client plugins are loaded and used via the Qt API, after examining the ParaView implementation. Server plugins are managed using vtkPVPluginLoader and custom code. We are:

• Creating server plugins containing vtkSNL filters that are used by the client, so we no-longer have to create a "custom" ParaView build (or deal with circular dependencies!).
• Using a client plugin to perform usage logging of the prototype.

Proposed New Plugin Types

AutoStart Plugins

An AutoStart plugin is a client-side plugin implementing API that is called at program start and program shutdown. AutoStart plugins are ideal for usage logging, since they can be created and distributed on a site-by-site basis to meet local needs. Our protoype has just such a plugin, which can replace several sets of platform-specific scripts and helper applications. The proposed new interface for AutoStart plugins is pqAutoStartInterface, which is already implemented in our prototype:

#include <QtPlugin>

/// Abstract interface for plugins that should be notified at program start / program shutdown
class pqAutoStartInterface
{
public:
  virtual ~pqAutoStartInterface() {}

  /// Called once after the program starts
  virtual void Startup() = 0;
  /// Called once before the program shuts down
  virtual void Shutdown() = 0;

protected:
  pqAutoStartInterface() {}
  pqAutoStartInterface(const pqAutoStartInterface&);
  pqAutoStartInterface& operator=(const pqAutoStartInterface&);
};

Q_DECLARE_INTERFACE(pqAutoStartInterface, "com.kitware/paraview/autostart")

EventLoop Plugins

An EventLoop plugin is a special-purpose plugin that is used to provide a ParaView user interface. Only one EventLoop plugin can be used by the application at-a-time, and an EventLoop plugin is a "wrapper" for a user event loop, the defining characteristic of any user interface. The current ParaView user interface would be encapsulated within an EventLoop plugin, and developers could create their own plugins as-needed. Note that an EventLoop plugin does not necessarily have to implement a graphical user interface - it could just as easily provide a Python interpreter (pvpython), a batch-execution interface (pvbatch), a web-service such as XML-RPC, or any other interface that waits in a loop for user input.

Due to its unique responsibility, an event loop plugin would have to be available / specified at program startup. Presumably, ParaView would automatically load its "standard" event loop plugin at startup without any user intervention, while a command line argument and/or environment variable could be used to specify an alternate plugin. Applications built on ParaView that provide their own custom user interface would use wrapper scripts or program icons to specify the correct event loop plugin automatically - users would not be aware of the underlying ParaView instance.

A (very rough) interface proposal for EventLoop plugins:

#include <QtPlugin>

/// Abstract interface for plugins that can wrap a user event loop
class pqEventLoopInterface
{
public:
  virtual ~pqEventLoopInterface() {}

  /// Called once when the application is ready for user input.
  /// This function does not return until the user has requested
  /// shutdown.  It is comparable to QApplication::exec(), and
  /// would likely be called from pqProcessModuleGUIHelper::RunGUIStart().
  virtual void StartEventLoop() = 0;
  /// Called to exit the event loop, so that StartEventLoop() returns.
  virtual void StopEventLoop() = 0;

protected:
  pqEventLoopInterface() {}
  pqEventLoopInterface(const pqEventLoopInterface&);
  pqEventLoopInterface& operator=(const pqEventLoopInterface&);
};

Q_DECLARE_INTERFACE(pqEventLoopInterface, "com.kitware/paraview/eventloop")