ParaView/Extending ParaView at Compile Time: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Plugin_HowTo|Plugins]] can be used to extend ParaView functionality. However, that requires that ParaView is built with shared libraries. It is also possible to extend ParaView at compile time by compiling extra source into it. This documents describes how that can be done.  
=Before ParaView 3.12=


In ParaView versions before 3.12, it was possible to bring in arbitrary code to extend the ParaView capabilities at compile time by setting EXTERNAL_MODULES to point to additional source directories. These sources included CMakeLists.txt files that used
PARAVIEW_INCLUDE_SERVERMANAGER_RESOURCES, PARAVIEW_INCLUDE_SOURCES, PARAVIEW_INCLUDE_GUI_RESOURCES, PARAVIEW_INCLUDE_WRAPPED_SOURCES macros to build additional components.
These made is possible to change ParaView build arbitrarily without any mechanism to catch issues with client and server don't match up. Hence, this has been deprecated with ParaView 3.12. If you want to use this mechanism for ParaView versions earlier than 3.12, refer to the history of this document [http://www.paraview.org/Wiki/index.php?title=Extending_ParaView_at_Compile_Time&oldid=13197].


Let's say we have a file format called '''MyFancy''' and we require a reader for it. The file format is something completely new, so we cannot reuse any other class. So we write our own VTK reader and now we want to use it in the ParaView. Let's say the header file for the reader looks like this:
=ParaView 3.12 Onwards=


<source lang="cpp">
Starting with ParaView 3.12, the ability to add arbitrary code to be included using EXTERNAL_MODULES has been deprecated. Instead one can point to directories containing additional plugins using EXTRA_EXTERNAL_PLUGIN_DIRS variable. Developers can then build standard plugins that will be included with the ParaView build. Since the custom code is encapsulated in plugins, it's possible to detect client-server mismatches and other conflicts/issues arising from such additions. Refer to [[ParaView/Plugin_HowTo#Adding_plugins_to_ParaView_source | ParaView Plugins - How To]] for requirements imposed on the source files within these plugin directories.
#ifndef __vtkMyFancyReader_h
#define __vtkMyFancyReader_h
 
#include "vtkUnstructuredGridAlgorithm.h"
 
...
 
class VTK_EXPORT vtkMyFancyReader : public vtkUnstructuredGridAlgorithm
{
public:
  static vtkMyFancyReader *New();
  vtkTypeMacro(vtkMyFancyReader,vtkUnstructuredGridAlgorithm);
  void PrintSelf(ostream& os, vtkIndent indent);
 
  // Description:
  // Specify file name of the MyFancy file.
  vtkSetStringMacro(FileName);
  vtkGetStringMacro(FileName);
 
  ...
 
protected:
  vtkMyFancyReader();
  ~vtkMyFancyReader();
 
  ...
 
private:
  vtkMyFancyReader(const vtkMyFancyReader&); // Not implemented
  void operator=(const vtkMyFancyReader&); // Not implemented
};
 
#endif
</source>
 
First, we need to write the server manager configuration XML describing the interface.
 
<source lang="xml">
  <ServerManagerConfiguration>
    <ProxyGroup name="sources">
      <SourceProxy name="MyFancyReader"
                  class="vtkMyFanceReader">
        <StringVectorProperty name="FileName"
                              command="SetFileName"
                              number_of_elements="1">
          <FileListDomain name="files"/>
          <Documentation>
            This property specifies the file name for the PNG reader.
          </Documentation>
        </StringVectorProperty>
      </SourceProxy>
  </ProxyGroup>
</ServerManagerConfiguration>
</source>
 
Readers, Writers, and Filters also require additional GUI side XML to describe file extensions associated with those file types.
 
<pre><nowiki>
<ParaViewReaders>
  <Reader name="MyFancyReader"
          extensions="myfan"
          file_description="My Fancy Files">
  </Reader>
</ParaViewReaders>
</nowiki></pre>
 
<pre><nowiki>
<ParaViewFilters>
  <Filter name="MyFancyFilter" />
</ParaViewFilters>
</nowiki></pre>

Latest revision as of 19:20, 22 August 2012

Before ParaView 3.12

In ParaView versions before 3.12, it was possible to bring in arbitrary code to extend the ParaView capabilities at compile time by setting EXTERNAL_MODULES to point to additional source directories. These sources included CMakeLists.txt files that used PARAVIEW_INCLUDE_SERVERMANAGER_RESOURCES, PARAVIEW_INCLUDE_SOURCES, PARAVIEW_INCLUDE_GUI_RESOURCES, PARAVIEW_INCLUDE_WRAPPED_SOURCES macros to build additional components. These made is possible to change ParaView build arbitrarily without any mechanism to catch issues with client and server don't match up. Hence, this has been deprecated with ParaView 3.12. If you want to use this mechanism for ParaView versions earlier than 3.12, refer to the history of this document [1].

ParaView 3.12 Onwards

Starting with ParaView 3.12, the ability to add arbitrary code to be included using EXTERNAL_MODULES has been deprecated. Instead one can point to directories containing additional plugins using EXTRA_EXTERNAL_PLUGIN_DIRS variable. Developers can then build standard plugins that will be included with the ParaView build. Since the custom code is encapsulated in plugins, it's possible to detect client-server mismatches and other conflicts/issues arising from such additions. Refer to ParaView Plugins - How To for requirements imposed on the source files within these plugin directories.