This is again a concept question regarding the new project setup for version 5.7.
My very first expectation was that if I can define “modules”, these could contain a number of “plugins”, eg. if they are actually a set of tools relating to the same kind of job.
But then looking into both the examples code and the real PV production code, I have not find such a case yet - and I am having doubts if it can be done or not?
There are “modules” containing lots of classes, wether they are filters or just any other code where bringing them together into “modules” makes a lot of sense. But it looks like as soon as a class stands for a plugin, it has to have it’s “module” of it’s own - right?
In any case I see always a first level of subdirectory that contains the paraview.plugin file, and within that another subdirectory with the vtk.module, suggesting that “module is contained inside plugin”, not the other way round!
I also saw that the build system is always generating two shared libraries in such a case: one for the module, and one for the plugin. Maybe the “module” is the actually classes, compiled C++ code, while the “plugin” is more or less only the CS interface from the XML? In which case I could maybe define the two separately: one folder with the sources defining the “module”, and independently a number of folders with only CS XML files defining the “plugins”?
First question: should the latter work at all? Ok, I could try…
Second question: would it be good practice, meaning that the “1 plugin == 1 module” approach would be recommended?
a module cannot contains nor depends to a plugin, afaik.
a plugin (which is internally a module), can depends on any number of modules
a modules can depends on any number of modules
a plugin has no limitation in the number of features they can add to paraview.
different plugins can depends on the same module.
The folder architecture does not matter, even though examples does not make that evident.
My recommendation is as follows :
Define as many modules as you want, organizing them so dependency is logical and practical.
Define one plugin for one concept, it can depend on multiple modules, or on a single one.
Avoid having to many plugins, especially if they are loaded by default in your application, as that will clutter the Plugin Manager dialog.
Thanks! So plugins and modules are more or less completely different concepts within Paraview - makes sense.
Makes sense as well because it is useless to have default loaded plugins in the plugin manager because loading is not any more required and unloading not possible.
However, how do I get them into the main application? Load them statically and only call some initialization function?
Thanks for the link: that page looks new to me or pretty much updated!
But you planted now the idea into my brain that I should somehow avoid having plugins that are loaded anyway listed in the plugin manager, but I did not find a way so far how to avoid it!
Static or dynamic loading of the code is probably not the main point, but still somehow PV avoids it to have ALL the plugins (filters, sources, views etc. etc.) show up in the plugin manager; only the optional plugins are there.
Plus mine! But they are always loaded, and right now, in the new 5.7 setup, I am loading them with
in the main window constructor because the promoted way of loading them with REQUIRED_PLUGINS in paraview_client_add loads them too late - at least the one that is needed for my customized render view that is supposed to be the default view - from the first beginning. Which means that it must be loaded before the “behaviours” are generated.
Long question short:
How is the Clip filter being loaded without appearing in the plugin manager?
Well the Clip filter is not a provided by a plugin but is defined within the sources of ParaView, in filters.xml.
If you want to load a plugin without it appearing in the plugin manager, I do not think it is supported yet.
It shouldn’t be too hard to add though. Feel free to open an issue related to it.
(This may be untrue for static plugins, you may have to test for yourself).
Right, that’s the direction that I am heading: Somehow make the code of the filters part of the application itself, whether it is now statically linked or dynamically, and then load some kind of “myfilters.xml” that tells the server manager about the existing filter classes in the code.
And I understand now that the “trick” of not showing in the plugin manager is simply: do not make it a plugin at all!
In other words:
I have to write the code for my filters etc. in modules - which is the way to go now anyway -, and link it to the main program.
Then I need to load the client server configuration XML not through a plugin, but in the way that also the filters.xml is being loaded.
It comes in through the pvParaViewInitializer plugin. This does the plugin machinery manually and is loaded from ParaView’s initialization logic since “everything” in ParaView needs this plugin available to actually get any work done.
Yes. Plugins are dynamically loaded and provide additional functionality to a client (of which bin/paraview is one). Modules are libraries and have an SDK for use from other C++ code. These support being wrapped in various tools via properties set by the module system. Plugins may want to have code which gets wrapped. Since the wrappers work on the module system’s extra properties, these are made into modules which are then “privatized” by the plugin system to not install an SDK. It does the CS wrapping and places it into the plugin, suppresses SDK installation for the private module, and places its library next to the plugin itself.
The client logic can take the output from the plugin build infrastructure to make it easy to use those plugins through its CMake API.