1 # Plugin Howto {#PluginHowto}
5 ParaView comes with plethora of functionality bundled in: several readers,
6 multitude of filters, different types of views, etc. However, it is not
7 uncommon for developers to want to add new functionality to ParaView to, for
8 example, add support to their new file format or incorporate a new filter into
9 ParaView. ParaView makes it possible to add new functionality by using an
10 extensive plugin mechanism.
12 Plugins can be used to extend ParaView in several ways:
14 * Add new readers, writers, filters
15 * Add custom GUI components such as toolbar buttons to perform common tasks
16 * Add new views in for display data
18 Examples for different types of plugins are provided with the ParaView source
19 under `Examples/Plugins/`.
21 This document has major sections:
23 * First section covers how to use existing plugins in ParaView.
24 * Second section contains information for developers about writing new
31 Plugins are distributed as shared libraries (`*.so` on Unix and macOS, and
32 `*.dll` on Windows). For a plugin to be loadable in ParaView, it must be built
33 with the same version of ParaView as it is expected to be deployed on. Plugins
34 can be classified into two broad categories:
36 * *Server-side plugins*: These are plugins that extend the algorithmic
37 capabilities for ParaView. For example, new filters, readers or writers.
38 Since ParaView processes data on the server-side, these plugins need to be
40 * *Client-side plugins*: These are plugins that extend the ParaView GUI
41 including property panels for new filters, toolbars or views. These plugins
42 need to be loaded on the client.
44 Oftentimes a plugin has both server-side as well as client-side components to
45 it. For example, a plugin that adds a new filter and a property panel that goes
46 with that filter. Such plugins need to be loaded both on the server as well as
49 Generally, users don't have to worry whether a plugin is a server-side or
50 client-side plugin. Simply load the plugin on the server as well as the client.
51 ParaView will include relevant components from plugin on each of the processes.
55 There are four ways for loading plugins:
57 * *Using the GUI* (`Plugin Manager`)
58 - Plugins can be loaded into ParaView using the `Plugin Manager` accessible
59 from the `Tools | Manage Plugins/Extensions` menu. The `Plugin Manager`
60 has two sections for loading client plugins and server plugins (shown
61 only when connected to a server). To load a plugin on the client and
62 server side, simply browse to the plugin shared library. If the plugin is
63 loaded successfully, it will appear in the list of loaded plugins. The
64 `Plugin Manager` also lists the paths it searched to load plugins
66 - The `Plugin Manager` remembers all loaded plugins across ParaView
67 instances, so once a plugin is loaded once, it will appear in the future
69 - You can set up ParaView to automatically load the plugin at startup (for
70 client plugins) or on connecting to the server (for server plugins) by
71 checking the "Auto Load" checkbox on a loaded plugin.
73 ![Plugin Manager when not connected to a remote server, showing loaded plugins on the local site.](images/LocalPlugin_Manager.png)
74 ![Plugin Manager when connected to a server showing loaded plugins on the local as well as remote sites.](images/RemotePlugin_Manager.png)
76 * *Using environment variable* (Auto-loading plugins)
77 - In order to have ParaView automatically load a set of plugins on startup,
78 one can use the `PV_PLUGIN_PATH` environment variable. `PV_PLUGIN_PATH`
79 may be used to list a set of directories (separated by colon (`:`) for
80 Unix platforms or semi-colon (`;`) on Windows) which ParaView will search
81 on startup to load plugins. This environment variable needs to be set on
82 both the client and server sides to load their respective plugins. Note
83 that plugins in PV_PLUGIN_PATH are always auto-loaded irrespective of the
84 status of the `Auto Load` checkbox in the `Plugin Manager`. Paths in this
85 list may also be of the structure created by the ParaView plugin macros
86 (e.g., `MyPlugin/MyPlugin.so`).
87 - Finer control can be used using the `PV_PLUGIN_CONFIG_FILE` environment
88 variable. `PV_PLUGIN_CONFIG_FILE` can be used to list a set of XML plugin
89 configuration files (separated by colon (`:`) on Unix platforms or
90 semi-colon (`;`) on Windows). ParaView will read these files on startup
91 to load specified plugins. The XML plugin configuration file format looks
97 <Plugin name="MyPlugin" filename="/absolute/path/to/libMyPlugin.so"/>
98 <!-- Note that relative paths are calculated from the directory of this XML file. -->
99 <Plugin name="MyPluginRel" filename="relative/path/to/libMyPlugin.so"/>
103 Plugins listed this way will always be loaded, irrespective of the status
104 of the `Auto Load` checkbox in the `Plugin Manager`.
105 * *Using the plugin file `.plugins`* (Make plugins available and possibly
107 - Plugins that are listed in the `.plugins` file on the client and server
108 will automatically be listed in the `Plugin Manager`, and may optionally
109 be auto loaded. ParaView creates its own `.plugins` file listing plugins
110 known during its build and uses it as the default. An example `.plugins`
111 file, auto loading H5PartReader, looks like this:
114 <?xml version="1.0"?>
116 <Plugin name="Moments" auto_load="0"/>
117 <Plugin name="PrismPlugin" auto_load="0"/>
118 <Plugin name="PointSprite_Plugin" auto_load="0"/>
119 <Plugin name="pvblot" auto_load="0"/>
120 <Plugin name="H5PartReader" auto_load="1"/>
124 * *Default search paths*
125 - Recognized locations are:
126 * A `plugins` subdirectory under the `paraview-X.Y` directory in the
127 library path (usually `lib` on Unix platforms and `bin` on Windows).
131 If plugin loading fails, the `PV_PLUGIN_DEBUG` environment variable may be set
132 for either the client or server processes. ParaView will then print verbose
133 information about each step and causes for failure, as show below.
136 ***************************************************
137 Attempting to load /home/utkarsh/Kitware/ParaView3/ParaView3Bin/bin/libSurfaceLIC.so
138 Loaded shared library successfully. Now trying to validate that it's a ParaView plugin.
139 Updating Shared Library Paths: /home/utkarsh/Kitware/ParaView3/ParaView3Bin/bin
140 Plugin instance located successfully. Now loading components from the plugin instance based on the interfaces it implements.
141 ----------------------------------------------------------------
148 ServerManager Plugin : Yes
154 This section covers writing and compiling different types of Plugins. To create
155 a plugin, one must have their own build of ParaView. Binaries downloaded from
156 www.paraview.org do not include necessary header files or import libraries
157 (where applicable) for compiling plugins.
159 The `CMakeLists.txt` file used in all following examples start off with the
163 # ParaView requires CMake 3.8 in order to be used.
164 cmake_minimum_required(VERSION 3.8)
165 project(myplugin C CXX)
167 find_package(ParaView REQUIRED)
170 Where CMake will ask for the `ParaView_DIR` which you point to the ParaView
171 build or install tree you would to build your with.
173 Note that the `C` and `CXX` languages are required in general because ParaView
174 may need to find other packages which are written with only C in mind (MPI is
175 the usual culprit here) and need to know about the C compiler that is
178 ## Exposing an Existing Filter
180 Sometimes, the filter that one wants to add to ParaView is already available in
181 VTK, it's just not exposed through the ParaView GUI. This is the easiest type
182 of plugin to create. There are two options:
184 1. setup the plugin using only an XML file; and
185 2. actually compile the plugin into a shared library.
187 The first option is the easiest, but the second option will prepare you for
188 creating a custom filter in the future as the process is nearly identical.
190 ## Adding a New Filter
192 It is also possible to add new filters to ParaView. The filter has to be a
193 VTK-based algorithm, written as following the standard procedures for writing
194 VTK algorithms. Generally for such cases where we are adding a new VTK class to
195 ParaView (be it a filter, reader or a writer), we need to do the following
198 * Write a *Server Manager Configuration XML* which describes the `Proxy`
199 interface for the filter. Basically, this defines the interface for the
200 client to create and modify instances of the new class on the server side.
201 Please refer to the [ParaView Guide][] for details about writing these
203 * Write a configuration XML for the GUI to make ParaView GUI aware of this
204 new class, if applicable. For filters, this is optional, since ParaView
205 automatically recognizes filters added through plugins and lists them in
206 the *Alphabetical* sub-menu. One may use the GUI configuration XML to add
207 the new filter to a specific category in the *Filters* menu, or add a new
208 category. For readers and writers, this is required since ParaView GUI
209 needs to know what extensions your reader/writer supports etc.
213 Plugins may access resources relative to themselves by using the
214 `paraview_plugin_add_location` interface to get the location of the plugin at
215 runtime. Note that this only works when built as a shared plugin. For static
216 plugins, the path will come in as a `nullptr`. If a plugin with resources
217 intends to support resources, it is recommended to use a `.qrc` file to embed
218 the resources into the plugin.
220 For installation of resources, the `_paraview_build_plugin_directory` variable
221 contains the location of the plugin under the build and install prefixes. Build
222 resources may be placed under
223 `"${CMAKE_BINARY_DIR}/${_paraview_build_plugin_directory}"` and installed with
224 `DESTINATION "${_paraview_build_plugin_directory}"`. The plugin itself belongs
225 to the `${_paraview_build_PLUGINS_COMPONENT}` component, so resources should
226 generally use a component with a related name.
232 If you have not built ParaView from source, using an XML plugin is your only
235 First, a server manager XML for the filter is required. The GUI XML to add the
236 filter to any specific category is optional.
238 For example, let's say we simply want to expose the `vtkCellDerivatives` filter
239 in VTK. Then first, we'll write the server manager configuration XML (call it
240 `CellDerivatives.xml`), similar to what we would have done for adding a new
244 <ServerManagerConfiguration>
245 <ProxyGroup name="filters">
246 <SourceProxy name="MyCellDerivatives" class="vtkCellDerivatives" label="My Cell Derivatives">
248 long_help="Create point attribute array by projecting points onto an elevation vector."
249 short_help="Create a point array representing elevation.">
253 command="SetInputConnection">
254 <ProxyGroupDomain name="groups">
255 <Group name="sources"/>
256 <Group name="filters"/>
258 <DataTypeDomain name="input_type">
259 <DataType value="vtkDataSet"/>
264 </ServerManagerConfiguration>
267 At this point, we can stop and use the plugin in ParaView by loading the XML
268 file directly into the plugin manager.
270 Please note that if you are writing the XML for a filter that takes just one
271 input, you *must* set the `name` attribute for the `InputProperty` XML element
272 to `Input`. If you do not, then the filter will not be displayed properly in
273 ParaView's pipeline browser.
275 ### Compiling into a Shared Library
277 If you have built ParaView from source, it is possible to compile the plugin
278 into into a shared library. To do this, we can use the following top-level:
282 # Standard CMake boilerplate. ParaView's `find_package` requires at least 3.8.
283 cmake_minimum_required(VERSION 3.8)
284 project(sharedlibrary)
286 # These five lines are required in order to set up installation directories
287 # (which also control build directory locations) and enable shared builds
288 # (CMake's default is for a static build).
289 include(GNUInstallDirs)
290 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}")
291 set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
292 set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
293 set(BUILD_SHARED_LIBS ON)
295 # Find ParaView. This will bring in ParaView's CMake API and imported targets.
296 find_package(ParaView REQUIRED)
298 # Scan the plugin file in order to set up internal data structures for building
300 paraview_plugin_scan(
301 # The `paraview.plugin` file describing the plugin.
302 PLUGIN_FILES "${CMAKE_CURRENT_SOURCE_DIR}/Plugin/paraview.plugin"
303 # A result variable for the (enabled) plugins found during the scan.
304 PROVIDES_PLUGINS plugins
305 # Enable plugins during this scan by default.
306 ENABLE_BY_DEFAULT ON)
308 # Build the plugins discovered during the scan.
309 paraview_plugin_build(
313 The mentioned `paraview.plugin` file describes the plugin to the build system:
319 Expose the vtkCellDerivatives class to ParaView.
321 # This module provides the `vtkCellDerivatives` filter.
325 In the `Plugin` directory (beside the `paraview.plugin` file), the plugin is
326 given the information it needs to build:
329 paraview_add_plugin(CellDerivatives
331 SERVER_MANAGER_XML CellDerivatives.xml)
334 Then using CMake, one can build a plugin for this new filter. We can now load
335 the plugin through the plugin manager by selecting the created `.so` or `.dll`
338 ### Qt resource plugins
340 Similarly compiled Qt resources (`*.bqrc`) can be loaded at runtime. A `.bqrc`
341 file is a binary file containing resources which can include icons, the GUI
342 configuration XML for adding categories, etc. A `.bqrc` can be made from a
343 `.qrc` by running the `rcc` utility provided by Qt:
346 rcc -binary -o myfile.bqrc myfile.qrc
349 ### Adding a New Filter
351 For this example, refer to `Examples/Plugins/ElevationFilter` in the ParaView
352 source. Let's say we have written a new `vtkMyElevationFilter`
353 (`vtkMyElevationFilter.{h,cxx}`), which extends the functionality of the
354 `vtkElevationFilter` and we want to package that as a plugin for ParaView. For
355 starters, we simply want to use this filter in ParaView (e.g., not doing
356 anything fancy with *Filters* menu categories). As described, we need to write
357 the server manager configuration XML (`MyElevationFilter.xml`). Once that's
358 done, we write a `CMakeLists.txt` file to package this into a plugin.
360 This `CMakeLists.txt` needs to include the following lines:
363 cmake_minimum_required(VERSION 3.8)
366 include(GNUInstallDirs)
367 set(BUILD_SHARED_LIBS ON)
369 find_package(ParaView REQUIRED)
371 paraview_plugin_scan(
372 PLUGIN_FILES "${CMAKE_CURRENT_SOURCE_DIR}/Plugin/paraview.plugin"
373 PROVIDES_PLUGINS plugins
374 ENABLE_BY_DEFAULT ON)
376 paraview_plugin_build(
380 The referenced `paraview.plugin` file contains:
386 An example paraview plugin containing server manager XML and the server
387 manager classes to build. This plugin can be loaded on the server side.
393 And the `CMakeLists.txt` file beside it contains:
396 paraview_add_plugin(ElevationFilter
398 MODULES ElevationFilters
399 MODULE_FILES "${CMAKE_CURRENT_SOURCE_DIR}/ElevationFilters/vtk.module")
402 Because we are building our own custom filter, it needs to be a VTK module in
403 order to support having its information available to the XML code. First, the
404 module is declared in a `vtk.module` file:
415 And then the module is built with its associated server manager XML file
416 attached to the module. Note that the module name cannot be the same as the
417 plugin name due to the way the library targets are managed internally.
421 vtkMyElevationFilter)
423 # Find external packages here using `find_package`.
425 vtk_module_add_module(ElevationFilters
428 # Link to external packages here using `vtk_module_link(ElevationFilters)`.
430 paraview_add_server_manager_xmls(
431 XMLS MyElevationFilter.xml)
434 Then using CMake, one can build a plugin for this new filter. Once this plugin
435 is loaded the filter will appear under the *Alphabetical* list in the *Filters*
436 menu. Note that there will be two libraries in the resulting directory. Be sure
437 to load the `ElevationFilter` one which is the plugin, not the
438 `ElevationFilters` module library.
440 ### Filters with Multiple Input Ports
442 If a filter requires multiple input ports, there are two options:
444 1. Create helper functions in the VTK filter such as `SetYourInputName` which
445 deal with addressing the VTK pipeline in the C++ code; and
446 2. Address/access the input connection by number in the XML. The `port_index`
447 property specifies which input connection the particular input will be
448 connected to. The `SetInputConnection` function is the command that will
449 actually be called with this `port_index` to setup the pipeline.
451 An example XML file for a filter with multiple inputs is below. The filter
452 takes three `vtkPolyData` objects as input.
455 <ServerManagerConfiguration>
456 <ProxyGroup name="filters">
457 <SourceProxy name="LandmarkTransformFilter" class="vtkLandmarkTransformFilter" label="LandmarkTransformFilter">
459 long_help="Align two point sets using vtkLandmarkTransform to compute the best transformation between the two point sets."
460 short_help="vtkLandmarkTransformFilter.">
464 name="SourceLandmarks"
466 command="SetInputConnection">
467 <ProxyGroupDomain name="groups">
468 <Group name="sources"/>
469 <Group name="filters"/>
471 <DataTypeDomain name="input_type">
472 <DataType value="vtkPolyData"/>
475 Set the source data set. This data set that will move towards the target data set.
480 name="TargetLandmarks"
482 command="SetInputConnection">
483 <ProxyGroupDomain name="groups">
484 <Group name="sources"/>
485 <Group name="filters"/>
487 <DataTypeDomain name="input_type">
488 <DataType value="vtkPolyData"/>
491 Set the target data set. This data set will stay stationary.
498 command="SetInputConnection">
499 <ProxyGroupDomain name="groups">
500 <Group name="sources"/>
501 <Group name="filters"/>
503 <DataTypeDomain name="input_type">
504 <DataType value="vtkPolyData"/>
507 Set the source data set landmark points.
512 <!-- see below for what options to put here -->
517 </ServerManagerConfiguration>
520 To set the inputs in ParaView, simply select one of the inputs in the *Pipeline
521 Browser* and then select the filter from the *Filters* menu. This will open a
522 dialog box which will allow you to specify which object to connect to each
525 ### Adding *Categories* to the *Filters* Menu
527 Now suppose we want to add a new category to the *Filters* menu, called
528 *Extensions* and then show this filter in that menu. In that case we need to
529 add a hint to the XML file that tells ParaView what category to display this
530 filter in. In this case, the `Hints` element of the XML file can contain:
534 <ShowInMenu category="Extensions" />
538 If the name of the category is same as an already existing category such as
539 *Data Analysis*, then the filter gets added to the existing category.
543 You can see that some filters in the *Filters* menu (e.g., *Clip*) have icons
544 associated with them. It's possible for the plugin to add icons for filters it
545 adds as well. For that you need to write a Qt resource file (say
546 `MyElevation.qrc`) as follows:
550 <qresource prefix="/MyIcons" >
551 <file>MyElevationIcon.png</file>
556 To use the icon for a filter in the pipeline add the following hint to the
561 <ShowInMenu icon=":/MyIcons/MyElevationIcon.png" />
565 Finally, the plugin's `CMakeLists.txt` file much change to include our
566 `MyElevation.qrc` file as follows:
569 paraview_add_plugin(ElevationFilter
571 MODULES ElevationFilters
572 MODULE_FILES "${CMAKE_CURRENT_SOURCE_DIR}/ElevationFilters/vtk.module"
573 UI_RESOURCES MyElevation.qrc)
576 ### Adding GUI Parameters
578 Simply add these in the server manager XML to expose parameters of the filter
579 to the ParaView user.
583 This property appears as a button containing the text described by the value of the "name" attribute, here: "My Button".
584 When a user click on the button, a call to the command, `MyButtonClicked` is performed directly on VTK class associated with the proxy.
589 command="MyButtonClicked">
593 #### Integer Property
595 This property appears as a text box.
599 name="bStartByMatchingCentroids"
600 command="SetbStartByMatchingCentroids"
601 number_of_elements="1"
606 #### Boolean Property
608 This property appears as a check box control. A boolean property uses the
609 `IntVectorProperty` with an extra line (`BooleanDomain`) indicating this should
610 be a check box rather than a text field.
614 name="bStartByMatchingCentroids"
615 command="SetbStartByMatchingCentroids"
616 number_of_elements="1"
618 <BooleanDomain name="bool"/>
624 This property appears as a text box.
627 <StringVectorProperty
628 name="YourStringVariable"
629 command="SetYourStringVariable"
630 number_of_elements="1"
632 </StringVectorProperty>
637 This property appears as a text box.
640 <DoubleVectorProperty
641 name="YourDoubleVariable"
642 command="SetYourDoubleVariable"
643 number_of_elements="1"
645 </DoubleVectorProperty>
648 #### Multi-Value Double Property
650 This property appears as a text box.
653 <DoubleVectorProperty
654 name="YourDoubleVectorVariable"
655 command="SetYourDoubleVectorVariable"
656 number_of_elements="3"
657 default_values="1.0 0.0 0.0">
658 </DoubleVectorProperty>
661 #### Double Property Slider
663 This creates a slider that ranges from `0.0` to `1.0`.
666 <DoubleVectorProperty
667 name="PercentToRemove"
668 command="SetPercentToRemove"
669 number_of_elements="1"
670 default_values="0.1">
671 <DoubleRangeDomain name="range" min="0.0" max="1.0" />
672 </DoubleVectorProperty>
677 This creates a drop down list with 3 choices. The values associated with the
678 choices may be specified.
683 command="SetTransformMode"
684 number_of_elements="1"
686 <EnumerationDomain name="enum">
687 <Entry value="6" text="RigidBody"/>
688 <Entry value="7" text="Similarity"/>
689 <Entry value="12" text="Affine"/>
692 This property indicates which transform mode will be used.
697 #### Drop Down List with Values from Input Arrays
699 This creates a list that lets you choose among the input arrays of the input of
700 a `ProgrammableFilter`:
703 <StringVectorProperty
704 name="SelectInputScalars"
706 command="SetInputArrayToProcess"
707 number_of_elements="5"
708 element_types="0 0 0 0 2"
712 attribute_type="Scalars"
713 input_domain_name="inputs_array">
715 <Property name="Input" function="Input" />
716 </RequiredProperties>
718 </StringVectorProperty>
721 This will look like the following image:
723 ![Drop down list with values from input arrays](images/DropboxWithInputArrays.jpg)
725 #### Drop Down List with Values from Input File
727 If you need to populate a list with values from a file and be able to
728 select/deselect list entries (e.g., to pick which variables are loaded from the
729 file), use a XML similar to this:
732 <StringVectorProperty information_only="1"
733 name="CellArrayInfo">
734 <ArraySelectionInformationHelper attribute_name="Cell" />
735 </StringVectorProperty>
736 <StringVectorProperty
737 command="SetCellArrayStatus"
739 information_property="CellArrayInfo"
741 name="CellArrayStatus"
742 number_of_elements="0"
743 number_of_elements_per_command="2"
745 <ArraySelectionDomain name="array_list">
747 <Property function="ArrayList"
748 name="CellArrayInfo" />
749 </RequiredProperties>
750 </ArraySelectionDomain>
752 This property lists which cell-centered arrays to read.
754 </StringVectorProperty>
757 You can see an example in use in ParaView's [core readers][] XML.
759 You may also do it in the following manner:
762 <StringVectorProperty
763 command="SetCellArrayStatus"
765 information_property="CellArrayInfo"
767 name="CellArrayStatus"
768 number_of_elements="0"
769 number_of_elements_per_command="2"
771 <ArrayListDomain name="array_list"
772 attribute_type="Scalars"
773 input_domain_name="inputs_array">
775 <Property name="Input" function="Input" />
776 </RequiredProperties>
778 </StringVectorProperty>
781 In which case the result will look like this:
783 ![Drop down list with values from input file](images/DropdownListFromFile.jpg)
785 <!-- TODO: port this section
786 #### Tutorials for creating filters ====
788 Go to this page for the main article for the tutorials: [[Python Filters Tutorials]]
793 Adding a new reader through a plugin is similar to adding a filter. The only
794 difference is that we do not need to specify what category the reader should be
795 added to in the GUI. For the latest version of ParaView we do not need to
796 specify anything special for the GUI as all of the details of the reader are
797 available in the XML proxy definition of the reader. For ParaView version 4.0.1
798 and earlier we need the XML to define what file extensions this reader can
799 handle. This XML (`MyReaderGUI.xml`) looks like this:
803 <Reader name="MyPNGReader" extensions="png"
804 file_description="My PNG Files">
809 An example `MyPNGReader.xml` is shown below. In almost all cases you must have
810 a `SetFileName` function property. You are free to have other properties as
811 well, as with a standard (non-reader) filter. Also, the `Hints` section is needed
812 in order to associate the file extension with the reader on the client. The
813 `ReaderFactory` hint is what the client uses to identify readers from sources.
815 Optionally, you can provide an information property `RegistrationName` to specify the reader
816 pipeline name to use. `RegistrationName` is a feature available for any proxy, not just readers.
819 <ServerManagerConfiguration>
820 <ProxyGroup name="sources">
821 <SourceProxy name="MyPNGReader" class="vtkMyPNGReader" label="PNGReader">
823 long_help="Read a PNG file."
824 short_help="Read a PNG file.">
826 <StringVectorProperty
829 command="SetFileName"
830 number_of_elements="1">
831 <FileListDomain name="files"/>
833 This property specifies the file name for the PNG reader.
835 </StringVectorProperty>
837 <StringVectorProperty
838 name="RegistrationName"
839 number_of_elements="1"
840 default_values="MyCustomName"
841 command="GetRegistrationName"
842 panel_visibility="never"
843 information_only="1">
845 This property specify the pipeline name for the reader, using the return value of `command`.
846 If `command` attributes is not specified, it uses `default_values`.
848 </StringVectorProperty>
851 <ReaderFactory extensions="png"
852 file_description="PNG File Format" />
856 </ServerManagerConfiguration>
859 The CMake code for a reader plugin uses the same structure as the filter
860 example. The only likely difference is that the plugin should also pass
861 `REQUIRED_ON_SERVER` to `paraview_add_plugin` since the server side needs the
862 reader available for its use.
864 If you want your reader to work correctly with a file series, please refer to [[Animating legacy VTK file series#Making custom readers work with file series|file series animation]] for details.
866 Once you generate the project using CMake and compile the project, in ParaView
867 go to *Tools > Manage Plugins/Extensions*. Under *Local Plugins*, click *Load
868 New* and browse for the shared library file you just created. You should now
869 see your new file type in the *Files of type* list in the *Open file* dialog.
873 Similar to a reader plugin, for a writer plugin we need to tell ParaView what
874 extensions this writer supports. For the current version of ParaView this is
875 done in the `Hints` section of the server manager XML definition as follows:
879 <WriterFactory extensions="tif"
880 file_description="My Tiff Files" />
884 #### Adding Customizations for Properties Panel
886 <!-- TODO link to external page -->
888 [[ParaView/Properties Panel|Properties Panel]] is the primary panel in ParaView
889 used to change the parameters for visualization modules and displays. Plugins
890 can provide new types of [`pqPropertyWidget`][pqPropertyWidget] subclasses that
891 can be used to control properties/property groups on this Properties panel.
893 To register a new `pqPropertyWidget` subclass to be associated with a
894 particular widget type for a property (`vtkSMProperty`), use the following
895 CMake code in your plugin:
898 paraview_plugin_add_property_widget
900 TYPE my_property_widget_type
902 INTERFACES interfaces
905 paraview_add_plugin(propwidget
907 UI_INTERFACES ${interfaces}
911 The `KIND` argument must be one of `WIDGET`, `GROUP_WIDGET`, or
912 `WIDGET_DECORATOR`. For a `vtkSMProperty`, `WIDGET` is required.
914 The `CLASS_NAME` argument must refer to a `pqPropertyWidget` subclass with a
915 constructor with the following signature:
918 ClassName(vtkSMProxy *smproxy, vtkSMProperty *smproperty, QWidget *parentObject)
921 The `TYPE` argument specifies the string that will be used in the server
922 manager XML as the value for the `panel_widget` attribute to request creation
923 of this widget for a `vtkSMProperty` subclass.
925 To register a new `pqPropertyWidget` subclass to be associated with a
926 particular widget type for a property group (`vtkSMPropertyGroup`), use
927 `GROUP_WIDGET` for the `KIND` argument. The referenced `CLASS_NAME` must
928 subclass `pqPropertyWidget` and have a constructor with the signature:
931 ClassName(vtkSMProxy *smproxy, vtkSMPropertyGroup *smgroup, QWidget *parentObject);
934 As before, the `TYPE` specifies the string that will be used in the server
935 manager XML as the value for the `panel_widget` attribute on a `PropertyGroup`
936 element to request creation of this widget for that group.
938 Another mechanism for adding customizations for *Properties* panel is to
939 provide [`pqPropertyWidgetDecorator`][pqPropertyWidgetDecorator] subclasses to
940 add custom control logic for widgets on the panel.
942 Decorators use the `WIDGET_DECORATOR` argument to `KIND`.
944 The `CLASS_NAME` must point to a `pqPropertyWidgetDecorator` subclass and the
945 `TYPE` is the string name used to request the creation of the decorator in the
946 server manager XML as described [[ParaView/Properties Panel|here]].
948 An example for customizing the Properties panel can be found in the ParaView
949 source under `Examples/Plugins/PropertyWidgets`.
951 #### Adding Documentation for Plugins
953 Developers can provide documentation for plugins that is shown in ParaView's
954 *Help* window. There are two mechanisms for adding documentation from plugins.
956 * Any server manager XML files added directly to the `paraview_add_plugin`
957 function or those attached to modules passed to its `MODULES` argument
958 using `paraview_add_server_manager_xmls` are automatically parsed to
959 process `Documentation` elements. HTML pages summarizing the proxy and
960 properties are automatically generated. This ensures that when the user
961 clicks "?" for a filter or source added via the plugin, the help window
962 shows appropriate help pages.
963 * Using the `DOCUMENTATION_DIR` argument to `paraview_add_plugin` to specify
964 a directory containing HTML pages and images that gets added a the
965 documentation for the plugin (in addition to the documentation generated
966 using the `SERVER_MANAGER_XML` files. For example:
969 paraview_add_plugin(SurfaceLIC
971 DOCUMENTATION_DIR "${CMAKE_CURRENT_SOURCE_DIR}/doc")
974 This results in adding documentation to the *ParaView Online Help* when the
975 plugin is loaded, as shown below.
977 ![](images/Paraview_doc_plugin.png)
979 It is also possible to customize further the documentation with 3 additional
982 * `DOCUMENTATION_ADD_PATTERNS`: If specified, add patterns to search for the
983 documentation files within `DOCUMENTATION_DIR` other than the default ones
984 (i.e. `*.html`, `*.css`, `*.png`, `*.js` and `*.jpg`). This can be used to
985 add new file extension (ex: `*.txt`) or even subdirectories (ex:
986 `subDir/*.*`). Subdirectory hierarchy is kept so if you store all of your
987 images in a `img/` sub directory and if your html file is at the root level
988 of your documentation directory, then you should reference them using
989 `<img src="img/my_image.png"/>` in the html file.
990 * `DOCUMENTATION_TOC`: If specified, the function will use the given string to
991 describe the table of content for the documentation. A TOC is divided into
992 sections. Every section points to a specific file (`ref` keyword) that is
993 accessed when selected in the UI. A section that contains other
994 sections can be folded into the UI. An example of such a string is:
998 <section title="Top level section title" ref="page1.html">
999 <section title="Page Title 1" ref="page1.html"/>
1000 <section title="Sub section Title" ref="page2.html">
1001 <section title="Page Title 2" ref="page2.html"/>
1002 <section title="Page Title 3" ref="page3.html"/>
1008 * `DOCUMENTATION_DEPENDENCIES`: Targets that are needed to be built before
1009 actually building the documentation. This can be useful when the plugin
1010 developer relies on a third party documentation generator like Doxygen for
1013 #### Adding a Toolbar
1015 Filters, reader, and writers are by far the most common ways for extending
1016 ParaView. However, ParaView plugin functionality goes far beyond that. The
1017 following sections cover some of these advanced plugins that can be written.
1019 Applications use toolbars to provide easy access to commonly used
1020 functionality. It is possible to have plugins that add new toolbars to
1021 ParaView. The plugin developer implements his own C++ code to handle the
1022 callback for each button on the toolbar. Hence one can do virtually any
1023 operation using the toolbar plugin with some understanding of the ParaView
1024 Server Manager framework and the ParaView GUI components.
1026 Please refer to `Examples/Plugins/SourceToolbar` for this section. There we are
1027 adding a toolbar with two buttons to create a sphere and a cylinder source. For
1028 adding a toolbar, one needs to implement a subclass for
1029 [`QActionGroup`][QActionGroup] which adds the [`QAction`][QAction]s for each of
1030 the toolbar button and then implements the handler for the callback when the
1031 user clicks any of the buttons. In the example `SourceToobarActions.{h,cxx}` is
1032 the `QActionGroup` subclass that adds the two tool buttons.
1034 To build the plugin, the `CMakeLists.txt` file is:
1037 # This is a macro for adding QActionGroup subclasses automatically as toolbars.
1038 paraview_plugin_add_action_group(
1039 CLASS_NAME SourceToolbarActions
1040 GROUP_NAME "ToolBar/SourceToolbar"
1041 INTERFACES interfaces
1044 # Now create a plugin for the toolbar. Here we pass the `interfaces` and
1045 # `sources` returned by the above call.
1046 paraview_add_plugin(SourceToolbar
1048 UI_INTERFACES ${interfaces}
1050 SourceToolbarActions.cxx)
1053 For the `GROUP_NAME`, we are using `ToolBar/SourceToolbar`; here `ToolBar` is a
1054 keyword which implies that the action group is a toolbar (and shows up under
1055 *View > Toolbars* menu) with the name `SourceToolbar`. When the plugin is
1056 loaded, this toolbar will show up with two buttons.
1060 Adding a menu to the menu bar of the main window is almost identical to adding
1061 a toolbar. The only difference is that you use the keyword `MenuBar` in lieu
1062 of `ToolBar` in the `GROUP_NAME` of the action group. So if you change the
1063 `paraview_plugin_add_action_group` command above to the following, the plugin
1064 will add a menu titled `MyActions` to the menu bar.
1067 paraview_plugin_add_action_group(
1068 CLASS_NAME SourceToolbarActions
1069 GROUP_NAME "MenuBar/MyActions"
1070 INTERFACES interfaces
1074 If you give the name of an existing menu, then the commands will be added to
1075 that menu rather than create a new one. So, for example, if the `GROUP_NAME`
1076 is `MenuBar/File`, the commands will be added to the bottom of the *File* menu.
1078 #### Adding a Context Menu
1080 Context menus are popup menus created when a user right-clicks inside a view
1081 (typically a render-view, but possible with any view). You can register a plugin
1082 that will create a context menu with items specific to the object underneath the
1083 cursor at the time the user right-clicks. The first instance of
1084 `pqContextMenuInterface` that returns a non-null menu is used; returning a
1085 null menu indicates the object(s) selected when the user right clicks are not
1086 relevant to your interface. For this reason, your subclass should avoid creating
1087 menus unrelated to a specific application or object type.
1089 To add a `pqContextMenuInterface` subclass to ParaView, simply pass your class
1090 name to the `UI_INTERFACES` argument of `paraview_add_plugin()` and the source,
1091 as usual, to the `SOURCES` argument:
1094 paraview_add_plugin(FancyMenu
1096 UI_INTERFACES FancyMenu
1097 SOURCES FancyMenu.h FancyMenu.cxx
1102 See the `Examples/Plugins/ContextMenu` directory for a simple example.
1104 #### Autostart Plugins
1106 This refers to a plugin which needs to be notified when ParaView starts up or
1107 the plugin is loaded which ever happens later and then notified when ParaView
1108 quits. Example is in `Examples/Plugins/Autostart` in the ParaView source. For
1109 such a plugin, we need to provide a `QObject` subclass
1110 (`pqMyApplicationStarter`) with methods that need to be called on startup and
1114 class pqMyApplicationStarter : public QObject
1118 // Callback for startup.
1119 // This cannot take any arguments
1122 // Callback for shutdown.
1123 // This cannot take any arguments
1128 The `CMakeLists.txt` looks as follows:
1131 # Macro for auto-start plugins. We specify the class name and the methods to
1132 # call on startup and shutdown on an instance of that class. It returns the
1133 # interface and sources created in the variables passed to the `INTERFACES` and
1134 # `SOURCES` arguments, respectively.
1135 paraview_plugin_add_auto_start(
1136 CLASS_NAME pqMyApplicationStarter # the class name for our class
1137 STARTUP onStartup # specify the method to call on startup
1138 SHUTDOWN onShutdown # specify the method to call on shutdown
1139 INTERFACES interfaces
1142 # Create a plugin for this starter
1143 paraview_add_plugin(Autostart
1145 UI_INTERFACES ${interfaces}
1146 SOURCES pqMyApplicationStarter.cxx ${interfaces})
1149 #### Getting the Location of a Dynamically-Loaded Plugin
1151 Some dynamically-loaded plugins include data or text files in the same
1152 directory as the plugin binary object (DLL or shared object). To locate
1153 these files at runtime, plugins can register a callback that is notified
1154 with the file system location of the plugin when it is loaded. To do this,
1155 we need to provide a `QObject` subclass (`pqMyLocationPlugin`) with a
1156 method to store the plugin location.
1159 class pqMyPluginLocation : public QObject
1163 // Callback when plugin is loaded.
1164 void StoreLocation(const char* location);
1168 The `CMakeLists.txt` looks as follows:
1171 # Macro for adding the location callback. We specify the class name and the
1172 # method to call with the filesystem location as `CLASS_NAME` and `STORE`
1173 # arguments. It returns the interface and sources created in the variables
1174 # passed to the `INTERFACES` and `SOURCES` arguments.
1175 paraview_plugin_add_location(
1176 CLASS_NAME pqMyPluginLocation # the class name for our class
1177 STORE StoreLocation # the method to call when the plugin is loaded
1178 INTERFACES interfaces
1182 #### Adding new Representations for 3D View using Plugins
1184 ParaView's 3D view the most commonly used view for showing polygonal or
1185 volumetric data. By default, ParaView provides representation-types for showing
1186 the dataset as surface, wireframe, points etc. It’s possible to add
1187 representations using plugins that extends this set of available
1188 representation types.
1190 Before we start looking at how to write such a plugin, we need to gain some
1191 understanding of the 3D view and its representations. The 3D view uses 3 basic
1192 representation proxies for rendering all types of data:
1194 * (representations, `UnstructuredGridRepresentation`) – for
1195 `vtkUnstructuredGrid` or a composite dataset consisting of
1196 `vtkUnstructuredGrid`.
1197 * (representations, `UniformGridRepresentation`) – for `vtkImageData` or a
1198 composite dataset consisting of `vtkImageData`
1199 * (representations, `GeometryRepresentation`) – for all other data types.
1201 Each of these representation proxies are basically composite representation
1202 proxies that use other representation proxies to do the actual rendering, e.g.,
1203 `GeometryRepresentation` uses `SurfaceRepresentation` for rendering the data as
1204 wireframe, points, surface, and surface-with-edges and `OutlineRepresentation`
1205 for rendering an outline for the data. Subsequently, the 3 composite
1206 representation proxies provide a property named `Representation` which allows
1207 the user to pick the representation type he wants to see the data as. The
1208 composite representation proxy has logic to enable one of its internal
1209 representations based on the type chosen by the user.
1211 These 3 composite representation types are fixed and cannot be changed by
1212 plugins. What plugins can do is add more internal representations to any of
1213 these 3 composite representations to support new representations types that the
1214 user can choose using the representation type combo box on the display tab or
1217 ![Representation type combo-box allowing user to choose the sub-representation to use](images/Representationplugin.png)
1219 ##### Using a New Mapper
1221 In this example, we see how to integrate a special polydata mapper written in
1222 VTK into ParaView. Let’s say the mapper is called `vtkMySpecialPolyDataMapper`
1223 which is simply a subclass of `vtkPainterPolyDataMapper`. In practice,
1224 `vtkMySpecialPolyDataMapper` can internally use different painters to do
1225 perform special rendering tasks.
1227 To integrate this mapper into ParaView, first we need to create a
1228 `vtkSMRepresentationProxy` subclass for that uses this mapper. In this example,
1229 since the mapper is a simple replacement for the standard
1230 `vtkPainterPolyDataMapper`, we can define our representation proxy as a
1231 specialization of the `SurfaceRepresentation` as follows:
1234 <ServerManagerConfiguration>
1235 <ProxyGroup name="representations">
1236 <RepresentationProxy
1237 name="MySpecialRepresentation"
1238 class="vtkMySpecialRepresentation"
1239 processes="client|renderserver|dataserver"
1240 base_proxygroup="representations"
1241 base_proxyname="SurfaceRepresentation">
1243 This is the new representation type we are adding. This is identical to
1244 the SurfaceRepresentation except that we are overriding the mapper with
1247 </RepresentationProxy>
1249 </ServerManagerConfiguration>
1252 `vtkMySpecialRepresentation` is a subclass of
1253 `vtkGeometryRepresentationWithFaces` where in the constructor we simply
1254 override the mappers as follows:
1257 vtkMySpecialRepresentation::vtkMySpecialRepresentation()
1259 // Replace the mappers created by the superclass.
1260 this->Mapper->Delete();
1261 this->LODMapper->Delete();
1263 this->Mapper = vtkMySpecialPolyDataMapper::New();
1264 this->LODMapper = vtkMySpecialPolyDataMapper::New();
1266 // Since we replaced the mappers, we need to call SetupDefaults() to ensure
1267 // the pipelines are setup correctly.
1268 this->SetupDefaults();
1272 Next we need to register this new type with the any (or all) of the 3 standard
1273 composite representations so that it will become available to the user to
1274 choose in the representation type combo box. To decide which of the 3 composite
1275 representations we want to add our representation to, think of the input data
1276 types our representation supports. If it can support any type of data set, then
1277 we can add our representation all the 3 representations (as is the case with
1278 this example). However if we are adding a representation for volume rendering
1279 of `vtkUnstructuredGrid` then we will add it only to the
1280 `UnstructuredGridRepresentation`. This is done by using the `Extension` XML
1281 tag. It simply means that we are extending the original XML for the proxy
1282 definition with the specified additions. Now to make this representation
1283 available as a type to the user, we use the `RepresentationType` element , with
1284 `text` used as the text shown for the type in the combo-box, `subproxy`
1285 specifies the name of representation subproxy to activate when the user chooses
1286 the specified type. Optionally one can also specify the `subtype` attribute,
1287 which if present is the value set on a property named `Representation` for the
1288 subproxy when the type is chosen. This allows for the subproxy to provide more
1289 than one representation type.
1292 <ServerManagerConfiguration>
1293 <ProxyGroup name="representations">
1294 <Extension name="GeometryRepresentation">
1296 Extends standard GeometryRepresentation by adding
1297 MySpecialRepresentation as a new type of representation.
1300 <!-- this adds to what is already defined in PVRepresentationBase -->
1302 subproxy="MySpecialRepresentation"
1303 text="Special Mapper"
1307 <Proxy name="MySpecialRepresentation"
1308 proxygroup="representations"
1309 proxyname="MySpecialRepresentation">
1311 <ShareProperties subproxy="SurfaceRepresentation">
1312 <Exception name="Input" />
1313 <Exception name="Visibility" />
1314 <Exception name="Representation" />
1319 </ServerManagerConfiguration>
1322 The `CMakeLists.txt` file is not much different from what it would be like for
1323 adding a simple filter or a reader where the representation class is placed
1324 into the contained module.
1326 Source code for this example is available under
1327 `Examples/Plugins/Representation` in the ParaView source directory.
1331 The ParaView git repository contains many examples in the `Examples/Plugins`
1334 ## Adding plugins to ParaView source
1336 There are several plugins that are included in ParaView source itself and are
1337 built as part of ParaView's build process. To add such a plugin to the ParaView
1338 build there are two options, adding it to the `ParaView/Plugins` directory is
1339 currently the only supported mechanism.
1341 <!-- TODO: Restore the external plugin building process to support custom plugins in static builds.
1343 1. Place the source for the plugin in a directory under `ParaView/Plugins`.
1344 2. Add the source directory to the CMake variable
1345 `EXTRA_EXTERNAL_PLUGIN_DIRS` when building ParaView.
1347 Both approaches result in identical behavior.
1350 In general users should simply build their plugins separately, outside the
1351 ParaView source. However, when building ParaView statically, adding the plugin
1352 to be built as part of ParaView ensures that the static executables load the
1353 plugin, otherwise there is no mechanism for loading a plugin in statically
1356 In your plugin source directory, ParaView searches for a file name
1357 `paraview.plugin` which provides ParaView with information about the plugin.
1358 This file should contain the following contents:
1361 # Comments are allowed.
1365 A description of the plugin. This text is attached to the CMake option to
1368 # List of VTK modules required by the code contained in the plugin. This
1369 # allows ParaView to build the full set of requested modules if the plugin is
1374 If now the plugin is enabled (by the user or by default) by turning ON the
1375 `PARAVIEW_PLUGIN_ENABLE_PluginName` CMake option, then CMake will look for a
1376 `CMakeLists.txt` file next to the `paraview.plugin`. This file contains the
1377 calls to build the plugin including the `paraview_add_plugin` call, and
1378 building of any other libraries that the plugin needs.
1380 A good place to start would be look at examples under `ParaView/Plugins`
1383 ## Plugins in Static Applications
1385 It is possible to import plugins into a ParaView-based application at compile
1386 time. When building ParaView-based applications statically, this is the only
1387 option to bring in components from plugins. When built statically (i.e., with
1388 `BUILD_SHARED_LIBS` set to false), ParaView will automatically link and load
1389 plugins that were enabled via CMake by inserting the necessary
1390 `PV_PLUGIN_IMPORT_INIT` and `PV_PLUGIN_IMPORT` macros.
1392 The code below shows how the `PV_PLUGIN` macros would be used to statically load
1393 plugins in custom applications:
1396 #define PARAVIEW_BUILDING_PLUGIN
1397 #include "vtkPVPlugin.h"
1399 // Adds required forward declarations.
1400 PV_PLUGIN_IMPORT_INIT(MyFilterPlugin)
1401 PV_PLUGIN_IMPORT_INIT(MyReaderPlugin)
1403 class MyMainWindow : public QMainWindow
1408 MyMainWindow::MyMainWindow(...)
1410 // ... after initialization ...
1412 // Calls relevant callbacks to load the plugins and update the
1413 // GUI/Server-Manager
1414 PV_PLUGIN_IMPORT(MyFilterPlugin);
1415 PV_PLUGIN_IMPORT(MyReaderPlugin);
1421 ### *Tools > Manage Plugins* is not visible!
1423 Plugins can only be loaded dynamically when ParaView is built with shared
1424 libraries. You must recompile ParaView with `BUILD_SHARED_LIBS=ON`.
1426 ### Compile error `invalid conversion from 'vtkYourFiltersSuperClass*' to 'vtkYourFilter*'`
1428 Any VTK object that needs to be treated as a filter or source has to be a
1429 `vtkAlgorithm` subclass. The particular superclass a filter is derived from has
1430 to be given not only in the standard C++ way:
1433 class VTKMODULE_EXPORT vtkMyElevationFilter : public vtkElevationFilter
1436 but additionally declared with help of the `vtkTypeMacro`. For the example
1440 class VTKMODULE_EXPORT vtkMyElevationFilter : public vtkElevationFilter
1443 vtkTypeMacro(vtkMyElevationFilter, vtkElevationFilter);
1447 Otherwise, compiling the filter will fail with a variety of error messages
1448 (depending on superclass) like
1451 vtkMyElevationFilter.cxx:19: error: no 'void vtkMyElevationFilter::CollectRevisions(std::ostream&)'
1452 member function declared in class 'vtkMyElevationFilter'
1457 vtkMyElevationFilterClientServer.cxx:97: error: invalid conversion from ‘vtkPolyDataAlgorithm*’ to
1461 ### Mysterious Segmentation Faults in Plugins that use Custom VTK Classes
1463 This primarily concerns plugins that make calls to your own custom `vtkMy` (or
1464 whatever you called it) library of VTK extensions.
1468 * The plugin will load, but causes a segfault when you try to use it.
1469 * If you use a debugger you may notice that in some cases when your code
1470 calls `vtkClassA.MethodB`, what actually gets called is
1471 `vtkClassC.MethodD`, where `MethodB` is a virtual member function. This is
1472 occurs because of different vtable entries in the Paraview-internal
1473 versions of the VTK libraries.
1475 The solution is to make sure that your `vtkMy` library is compiled against
1476 ParaView's internal VTK libraries. Even if you compiled VTK and ParaView using
1477 the same VTK sources, you *must not* link against the external VTK libraries.
1478 (The linker won't complain, because it will find all the symbols it needs, but
1479 this leads to unexpected behaviour.)
1481 To be explicit, when compiling your `vtkMy` library, you must set the CMake
1482 variable `VTK_DIR` to point to the `VTK` subdirectory in the directory in which
1483 you built ParaView. (On my system, CMake automatically finds VTK at
1484 `/usr/lib/vtk-5.2`, and I must change `VTK_DIR` to
1485 `~/source/ParaView3/build/VTK`.)
1487 ### "Is not a valid Qt plugin" in Windows
1489 Make sure that all the DLLs that your plugin depends on are on the `PATH`. If
1490 in doubt, try placing your plugin and all its dependent DLLs in the `bin`
1491 directory of your build and load it from there.
1493 ### The system cannot find the path specified. `error MSB6006: "cmd.exe" exited with code 3.`
1495 You may get an error like this when trying to build your plugin with
1499 1> CS Wrapping - generating vtkMyElevationFilterClientServer.cxx
1500 1> The system cannot find the path specified.
1501 1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
1502 1>Done executing task "CustomBuild" -- FAILED.
1505 This is caused for a mismatch between the configuration you used when building
1506 ParaView (e.g. Debug, Release, etc.) and the configuration currently chosen for
1507 building your plugin. So ensure those match.
1509 The problem is caused because inside the Linker properties there are references
1510 to the `*.lib` files, including the name of the directory that matches the
1511 configuration type, which may look something like
1512 `C:\Users\MyUser\ParaView-v4.2.0-build\lib\Release\vtkPVAnimation-pv4.2.lib`.
1514 ### Changing ParaView_DIR after the first configuration do not work as expected
1516 The plugin infrastructure and package finding logic do not support that as
1517 clearing the cache is not something we can reliably do as a config.cmake file.
1519 Just remove the build directory content and configure from scratch.
1521 [ParaView Guide]: http://www.kitware.com/products/books/paraview.html
1522 [core readers]: https://gitlab.kitware.com/paraview/paraview/-/blob/87babdbeab6abe20aac6f8b2692788abc6bb20ac/ParaViewCore/ServerManager/SMApplication/Resources/readers.xml#L158-179
1523 [pqPropertyWidget]: https://kitware.github.io/paraview-docs/nightly/cxx/classpqPropertyWidget.html
1524 [pqPropertyWidgetDecorator]: https://kitware.github.io/paraview-docs/nightly/cxx/classpqPropertyWidgetDecorator.html
1525 [QActionGroup]: https://doc.qt.io/qt-5/qactiongroup.html
1526 [QAction]: https://doc.qt.io/qt-5/qaction.html