|
|
| 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= |
|
| |
|
| ==Writing a New Reader== | | 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 include 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. |
| #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>
| |
| | |
| As described in the [[Plugin_HowTo|plugins]] documentation, we need to add GUI xml to tell ParaView about the supported extensions.
| |
| | |
| <source lang="xml">
| |
| <ParaViewReaders>
| |
| <Reader name="MyFancyReader"
| |
| extensions="myfan"
| |
| file_description="My Fancy Files">
| |
| </Reader>
| |
| </ParaViewReaders>
| |
| </source>
| |
| | |
| ==Build Code As Part Of ParaView==
| |
| | |
| One can also put new code into ParaView by just putting it in the ParaView source tree and modify the CMake lists files to compile its source files. The drawbacks of this approach are that we have to now maintain our own modifications to ParaView code, and we cannot use versioning software to maintain the history of our code. Well, at least not without some problems. The solution to this is to import the code to the ParaView build process using '''ParaView External Modules'''.
| |
| | |
| ParaView External Modules are collections of code that are included during the ParaView build process, but reside somewhere outside the ParaView source tree. To generate a ParaView External Module, we need to create a file called ''<nowiki><Module-Name></nowiki>ParaViewImport.cmake''. Let's say our module will be called MYFANCY, so the file needs to be called ''MYFANCYParaViewImport.cmake''. It will look like this:
| |
| | |
| <pre><nowiki>
| |
| SET (MYFANCY_SRCS
| |
| ${MYFANCY_SOURCE_DIR}/vtkMyFancyReader.cxx
| |
| )
| |
| | |
| INCLUDE_DIRECTORIES(${MYFANCY_SOURCE_DIR})
| |
| INCLUDE_DIRECTORIES(${MYFANCY_SOURCE_DIR}/..)
| |
| | |
| PARAVIEW_INCLUDE_WRAPPED_SOURCES("${MYFANCY_SRCS}")
| |
| </nowiki></pre>
| |
| | |
| To load this file into ParaView, we have to run the CMake GUI on ParaView and find an advanced option called '''PARAVIEW_EXTRA_EXTERNAL_MODULE'''. We should set it to '''MYFANCY'''. If it is already set to something, we should add MYFANCY to the list. For example: '''MYFANCY;ULTRASPECIAL'''. Once we run ''Configure'', a new option will appear called: '''PARAVIEW_USE_MYFANCY'''. To actually include the module, we need to set that option to '''ON'''. After running ''Configure'', CMake will attemt to find the MYFANCY source directory. If it cannot find the file ''MYFANCYParaViewImport.cmake'', it will produce an error that the source directory was not found. The CMake variable that specifies the location of the module source directory will be called ''<nowiki><Module-Name></nowiki>_SOURCE_DIR''. In our case this is '''MYFANCY_SOURCE_DIR'''. Note that this is the same variable used in the ''MYFANCYParaViewImport.cmake'' file. This variable should be set to the directory containing the ''MYFANCYParaViewImport.cmake'' file and not to the actual file.
| |
| | |
| At this point ParaView is all set to build. If all the locations are correct and the ''MYFANCYParaViewImport.cmake'' file is without errors, ParaView will be built with the reader included.
| |
| | |
| Additionally, you can use the following macros:
| |
| | |
| * To include Server manager XML:
| |
| | |
| PARAVIEW_INCLUDE_SERVERMANAGER_RESOURCES("${MYFANCY_SOURCE_DIR}/ServerManagerXML.xml")
| |
| | |
| * To include GUI Client XML:
| |
| | |
| PARAVIEW_INCLUDE_GUI_RESOURCES("${MYFANCY_SOURCE_DIR}/GUIXML.xml")
| |
| | |
| | |
| {{ParaView/Template/Footer}}
| |
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 include 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.
