After all I learned so far I know that I cannot simply write plugins for ParaView in C++, compile them as so or dll files and send them to somebody who has a ParaView installed from the “official” binary downloads: ParaView and the plugins need to be built with the same tools, libraries etc. in order to properly work together.
However, if the intended plugin already exists somewhere “hidden” in the VTK code it is possible to generate a plugin just by writing a proper XML file and import it into ParaView.
Still my question is if there is not still somehow a “way in between”. Like a way to write a Python script, refer to it in an XML server manager interface file and just import it - without taking care about compilation tools and libraries?
Even more interesting would be some kind of “plugin interface” that would at least loosen the need to recompile the entire thing for adding a plugin, but as far as I know this does not exist.
I know there are some other Open Source tools “out there” that seem to have kind of a generic plugin interface (QGIS, R…). However, I only used them regularly, but never programmed for these tools and have no clue how they are doing the trick. Of course there would always be limitations for such a solution.
Hi @cobo! In ParaView 5.6, an awesome new framework for building custom plugins was released: Python algorithm plugins. Essentially, you can write subclasses of VTKPythonAlgorithmBase and decorate those plugins using the new paraview.util.vtkAlgorithm module in ParaView. Here are some examples and here is a library (PVGeo) I’ve built with some 60+ algorithms under this framework.
Here’s a list of resources that might be helpful when developing Python VTK algorithms:
It brought me into the VTK docs where also the vtkProgrammableFilter exists that seems to do similar things, but with less type checking if I get it right.
Examples are all in Python - which I already assumed. Meaning that I have to do some more serious Python programming in order to go into that “business” than the few lines of code that I have written so far…
Regarding C++ I understand that you can of course make sure that you use the same tools, libraries and paraview versions for the plugin that were also used for the ParaView build. However, this may not always be practical.
My reasoning regarding Python was with a customer in mind who wants to have one or two plugins for some very specific evaluations which he does not want to disclose to the public, i.e. not integrate into the open source project. So if he has that plugin in Python at a time when PV 5.6 was current, he may carry that plugin further also to PV 5.7, 5.8 or maybe 6.0 etc., while a C++ plugin would at least need a recompilation.
Of course also with Python he would not have a guarantee that his plugin will work “infinitely”! So it is still a bit good luck if it works.
This is something I’ve been doing quite a bit lately! The Python plugins allow you to develop a single python file that can use external packages from a simple import statement and add new functionality that can be deployed totally separately and ready for any build of ParaView > 5.6.
Not to keep soliciting PVGeo on here but we have a framework there that works towards that “infinite” goal which may be insightful for others looking to develop their own Python-based plugins. We place all the algorithms (the subclasses of VTKPythonAlgorithmBase) in a standalone Python package where we can implement unit testing and continuous integration services like Travis CI. This makes PVGeo a standalone Python package which then has the extra wrappings to make all the classes in PVGeo plugins for ParaView. This ensures that the backend of PVGeo is always working on different Python distributions an provides a lightweight transfer to the PV plugin framework in the hopes that if anything on the PV side changes that it would be a simple fix/rewrite of the wrappings to make PVGeo compatible with future versions.