ParaView Plugins Implementation: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
 
Line 2: Line 2:


== Server vs. Client Plugins ==
== 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.
* 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 ==
== Server Plugins ==

Revision as of 17:55, 5 February 2007

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

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
    ...
  }
};

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\"> ....."
  }
};


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...)

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")