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 our main goal is to "subtract" features from the existing 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 managed via Qt, using code based on the ParaView implementation - we check for pqPlugin and iterate over its available interfaces, so our plugins should be "compatible" with ParaView, provided ParaView is updated to take advantage of any new plugin interfaces we create. 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 between vtkSNL and ParaView/VTK. This is a huge improvement in our build process!
• 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 replaces several high-maintenance sets of platform-specific wrapper 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")

After some discussions, we determined that the main part of this work is encompassing the majority of the boilerplate code that is required to build a vertical app. The autostart plugin basically just ignores the original GUI and builds its own. This is really exactly what a vertical app does. The only difference is that on approach builds a dll that a thin executable loads and the other builds an exe that runs on its own. There is no clear advantage of one over the other, and the one that gets implemented is probably just what makes more sense. --Ken 13:36, 5 March 2008 (EST)

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(int argc, char* argv[]) = 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")

Reverse Plugin

I have had a request for what I am calling a reverse plugin. Instead of ParaView pluging in some code, some other application plugs in ParaView to leverage its visualization and/or rendering. This has aspects of the previous two plugins. The external application (probably) won't use ParaView's GUI and it will most certainly have its own event loop. In addition, it will not be able to call vtkProcessModuleGUIHelper::Run and just stay there until everything is finished. Instead, the ParaView initialization should return and allow the calling external application continue processing and use ParaView on demand.

It may also be desirable to "hide" the ParaView render windows. The external application may have its own GUI setup and need ParaView to only generate images that it will use.

This type of plugin is of a lower priority than the other two. It is not required for OverView.