ParaView Plugins Implementation

ParaView_Plugins focuses on the use cases and how a developer would add a plugin. This page focuses on the actual implementation of plugins, the interfaces of which a developer of a plugin would be exposed to. This is a rough draft.

Server vs. Client Plugins

• Server plugins should not depend on Qt and should be loadable in an instance of pvserver.
• The client plugin implementation will use Qt's plugin code as much as possible.
• This doesn't prevent anyone from building one shared library with both server and client plugins in it.
• The Server and Client plugin design should be quite similar to ease development.

Server Plugins (Implementation 1)

These plugins can be used to include new VTK reader/writers/sources/filters.

vtkPVPlugin Interface

A plugin has one instance of vtkPVPlugin, which returns all interfaces the plugin implements.

class vtkPVPlugin
{
  public:
  vtkPVPlugin() {}
  ~vtkPVPlugin() {}
  virtual void GetInterfaces(vtkCollection* collection) = 0;
};
PARAVIEW_DECLARE_INTERFACE("com.Kitware.Paraview.InterfaceCollection")

Developers implement that interface as

class MyPVPlugin : public vtkObject, public vtkPVPlugin
{
  public:
  .. Standard VTK stuff ...

  void GetInterfaces(vtkCollection* collection)
  {
    ...
    add MyFancyReader to the collection
    ...
  }
};

I'm confused about what this class is providing. What is supposed to be put in collection? Is it an instance of each reader, filter, and writer the plugin provides? That makes little sense, because PV will still need to instantiate its own copies of these objects, and that is provided by the #vtkSMInterface Interface described below. What exactly does vtkPVPlugin provide?

--Ken 19:07, 5 Feb 2007 (EST)

It allows a plugin to provide implementation for more than one interface. --Clinton 20:41, 5 Feb 2007 (EST)

A macro will be provided to instantiate it and provide ParaView with entry points.

PARAVIEW_EXPORT_PLUGIN(MyPVPlugin)

vtkSMInterface Interface

An interface could be provided for adding readers/filters/etc...

class vtkSMInterface
{
  public:
  virtual ~vtkSMInterface() {}
  // add filters/readers to interpreter
  virtual void Initialize(vtkClientServerInterpreter* interp) = 0;
  // retrieve XML for readers/filters
  virtual const char* XML() = 0;
};
PARAVIEW_DECLARE_INTERFACE("com.Kitware.Paraview.Interface")

A developer would implement that interface

class MyFancyReader : public vtkObject, public vtkSMInterface
{
  public:
  .. Standard VTK stuff ...

  void Initialize(vtkClientServerInterpreter* interp)
  {
    ...
    add MyFancyReader to the interpreter
    ...
  }
  const char* XML()
  {
    // actually use kwProcessXML to generate this
    return "<ServerManagerConfiguration>\n<ProxyGroup name = \"readers\"> ....."
  }
};

How hard would it be to have CMake automatically generate the vtkSMInterface subclass? The files to be wrapped up for the client/server interpreter are already listed in the CMakeLists.txt, since it has to perform the actual wrapping. The server manager configuration files are also already listed in CMakeLists.txt since it has to run kwProcessXML to embed them in the library.

To simplify things for the user, could the CMake macro that makes the plugin automatically wrap the client server bindings, embed the xml, and generate the vtkSMInterface class? This should also make supporting the plugin easier since things like lists of class names need only be specified once in the CMakeLists.txt file rather than also in a cxx file.

--Ken 19:15, 5 Feb 2007 (EST)

Yes, it'll be possible to wrap all this up in CMake. If this is going to be the only interface ever created, then this is too much. I'll post another section for an alternate implementation. --Clinton 20:42, 5 Feb 2007 (EST)

Client Plugins

• Client plugins will work about the same, except that the interface implementations will derive from QObject instead of vtkObject.
• Qt macros will be used instead (Q_EXPORT_PLUGIN2, Q_DECLARE_INTERFACE, etc...)

What is the value added to using the Qt macros/plugin interface here? I could see how this would save on implementation time if we could always use it, but the server plugins need to be loaded without Qt. Using multiple mechanisms for loading plugins seems to add complexity in both the implementation and use of the plugin mechanism.

--Ken 19:20, 5 Feb 2007 (EST)

To implement a panel for a source proxy, one would implement this interface (which already exists in the code).

class PQCOMPONENTS_EXPORT pqObjectPanelInterface
{
 public:
  /// destructor
  virtual ~pqObjectPanelInterface() {}

  /// Returns true if this panel can be created for the given the proxy.
  virtual bool canCreatePanel(pqProxy* proxy) const = 0;
  /// Creates a panel for the given proxy
  virtual pqObjectPanel* createPanel(pqProxy* proxy, QWidget* p) = 0;

  virtual QString name() const = 0;
};

Q_DECLARE_INTERFACE(pqObjectPanelInterface, "com.kitware.paraview.objectpanel")