Regarding autoloading the plugins, this has been answered here :
Regarding the missing filters, they should be here and they are here in my Clone1 build. Do you have the same behavior with the default Clone1 application ?
Thanks for the pointer to the existing answer (thus indeed something has changed there!), and regarding the second - I will have to check again (because I was already at the point to compile “naked Clone1” and did not really pay attention). And then I will possibly/hopefully also find the answer.
…still I am not fully satisfied with that “solution” that is offered for the autoload question: All the three locations where I can put hands on the plugin loading process are not available at build time, but only once the software is already there!
Ok, for the superbuild you would have to introduce some funny magic to make it happen on the user computer during installation, but if I am about to build a PV derivative on my own computer, I have to do things completely outside of the build setup in order to get it happen.
In other words: I will probably find some workaround for myself, but overall I think that the removed PARAVIEW_AUTOLOAD_PLUGIN_* CMake options are leaving a gap that is not closed by the alternative ways to trigger autoloading - because the options were part of the build setup, while the others are not.
I definitely agree, that’s why I opened an issue :
https://gitlab.kitware.com/paraview/paraview/issues/19276
- It turned out that the disappearing “basic plugins” were due to the fact that I went a bit too far with renaming: I renamed the ParaViewFilters.xml (and similar) files to AthosGeoViewFilters.xml etc. - which is fine as long as I apply the same change also in the CMakeLists.txt file in the paraview_client_add call.
However, also inside the file I changed the tag in the same way - and this is obviously not recognized by the server manager!
- Just trying to add now also the “GeodesicMeasurement” filters to that XML tag, into some own submenu etc. I was asking myself whether this would already trigger an auto-load of the corresponsing plugin, but this is not the case (like the experts would have told me from the beginning…).
But after I loaded the GeodesicMeasurement plugin through the plugin manager, that new submenu appeared nicely, with the two filters that are part of the GeodesicMeasurement plugin.
- My next idea was to load the GeodesicMeasurement plugin like I always used to auto-load my own plugins - with the PV_PLUGIN_IMPORT_INIT macro in the header part of the cxx file of the main window class, and the PV_PLUGIN_IMPORT between the menu and the behaviour setup in the constructor.
However, it turned out that this macro is not defined, although vtPVPlugin.h is imported. BUT other than in earlier versions, the macros are defined between #ifdef PARAVIEW_BUILDING_PLUGIN … #endif - and that seems not to be defined! In version 5.6, this #ifdef was not there yet.
Which again raises two points:
a) for the purpose of autoloading the GeodesicMeasurement plugin it is probably the wrong approach anyway - because the plugin is already built (in the PV build), and it exists as a shared library, so no way to afterwards still linking it statically: should not work actually if I am thinking about it!
b) however, later on for my own plugins, I will eventually run into the problem again…
NOTE: I edited this post twice, so if you read an earlier version…
Workaround that is ugly but seems to work:
-
in the CMakeLists.txt file:
#we need Paraview here for the dependencies
find_package(ParaView REQUIRED)
#make sure AthosGeo can find optional ParaView plugins for explicit loading
configure_file(
“${CMAKE_CURRENT_SOURCE_DIR}/ParaViewPluginPath.h.in”
“${CMAKE_CURRENT_BINARY_DIR}/ParaViewPluginPath.h”) -
the ParaViewPluginPath.h.in has the following content:
#define PV_PATH_STRINGIFY(x) #x
#define PV_PATH_TOSTRING(x) PV_PATH_STRINGIFY(x)
#define PARAVIEW_PLUGIN_PATH @ParaView_DIR@/lib64/@PARAVIEW_PLUGIN_SUBDIR@
#define PARAVIEW_PLUGIN_PATH_STR PV_PATH_TOSTRING(PARAVIEW_PLUGIN_PATH) -
and finally at the end of the main window constructor I put the following code:
// explicitly load the GeodesicMeasurement plugin from ParaView
pqPluginManager* plgmgr = pqApplicationCore::instance()->getPluginManager();
std::string pluginLib = std::string(PARAVIEW_PLUGIN_PATH_STR) + “/GeodesicMeasurement/GeodesicMeasurement.so”;
QString err;
pqPluginManager::LoadStatus res = plgmgr->loadExtension(nullptr, pluginLib.c_str(),
&err, false);
With this I am getting the GeodesicMeasurement auto-loaded - just as an example. Of course this is only working with Linux so far (lib64 subdirectory and .so extension!), but a Windows version should be feasible as well - with some more ugly #if… code.
Easier solution - without the need to pass the Paraview directory from the CMake setup into the program (which is btw not working on the computer of a customer - because he will get the PV build path on the computer of the programmer…):
std::string plugin_xml = "<Plugins> <Plugin name=\"GeodesicMeasurement\" auto_load=\"1\" /> </Plugins>";
vtkSMProxyManager::GetProxyManager()->GetPluginManager()->LoadPluginConfigurationXMLFromString(plugin_xml.c_str(), nullptr, false);
This leaves the work of finding the plugins to the responsible instances within PV (ie, the plugin manager) and works with only the name - which should thus also be independent from the operating system and running environment at the customer’s site.
So the plugin stuff has been vastly improved on master the past few weeks. If you pass PLUGINS_TARGETS ParaView::paraview_plugins to the paraview_client_add function, your application will find ParaView plugins by default. However, ParaView still controls the AUTOLOAD status of them (which is currently failing due to the issue mentioned above). However, the plugins are now loadable by name since they’ve been found. You should be able to add any plugins you want to autoload in your application through the REQUIRED_PLUGINS argument to paraview_client_add. That makes the XML you’re referencing internally and does the same thing.
Thanks for the hint: It mostly worked for me - with my RC2 release that is two weeks old!
This is what I tried:
REQUIRED_PLUGINS
AcceleratedAlgorithms
ArrowGlyph
BagPlotViewsAndFilters,
GeodeticMeasurement,
EyeDomeLighting,
PanoramicProjectionView,
StreamLinesRepresentation)
Actually auto-loaded were AcceleratedAlgorithms, ArrowGlyph and StreamLinesRepresentation, while the others where present, but still had to be loaded manually.
The PLUGINS_TARGET with ParaView::paraview_plugins did not work, and to me it looks like such a target is not being defined by find_package(ParaView). At least this is what I conclude from the error message:
Target "AthosGeoView" links to target "ParaView::paraview_plugins" but the
target was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
Of course it is never really clear for the “non-initiated” which targets are available at a specific point and which not, but in this specific case I was first of all looking into ParaView_targets.cmake that is generated somewhere in the build target tree during the build of ParaView. There a list _expectedTargets is being initialized, and this does a lot of targets, but not any ParaView::paraview_plugins in my case.
Right at this moment I also downloaded the “master of the day”, and it is on the way to compile. Anyway, already I can say that the paraview_plugins target did not “appear” in that newer release.
The , (comma) you have on some of those would be a problem 
. The PLUGINS_TARGETS magic is only on master (it was too invasive to the plugin system to backport to 5.7).
The commas were the problem indeed - THANKS! (commas are C++, not CMake…) Much easier solution than moving ahead to “master” and trying whether this would bring the solution…
So I will stay with 5.7-RC2 (and eventually switch to the final release of 5.7), because basically I feel better if I take the train where it is standing in the station, not jumping in while it is running.
Next problem to solve: How do I get the “Reader, Filter and Writer Reference” into my custom application? So far I get only help for those filters that are loaded “later on” (ie the ones that are loaded with the REQUIRED_PLUGINS - like Geodesic Measurements), but not the “base items”. Instead in the “Output Messages” dock window it says “Could not locate index.html”.
But this is already a next question - and most likely I will have to find another stupid mistake…
Actually I found some solution: just include the existing paraview.qch file in the CMakeLists.txt file:
# access to the ParaView documentation
set(paraview_qch "${ParaView_DIR}/Applications/ParaView/Documentation/paraview.qch")
paraview_client_add(
NAME AthosGeoView
...
QCH_FILE
${paraview_qch}
REQUIRED_PLUGINS
AcceleratedAlgorithms
ArrowGlyph
BagPlotViewsAndFilters
GeodeticMeasurement
EyeDomeLighting
PanoramicProjectionView
StreamLinesRepresentation)
The result is so far ok for me:
Which means that I have now exactly the ParaView help from the underlying ParaView, plus separate Help sections from those optional plugins that are providing them.
Later I will have to add another Help section - for my own extensions! And for that I will try to find out how that paraview.pch is generated, and then add it to the Help system - ideally in such a way that it would come before the ParaView help. A test showed me that I can actually have more than one .qch files in that QCH_FILE section: I included a CMake manual first, and result was indeed that I had now first a CMake manual, then the ParaView manual, and then again the optional plugins documentation.
Maybe there are more elegant solutions (that would e.g. not require the relative path of the paraview.qch file below the ParaView_DIR path), but at least it works now!
This MR should make it clearer that multiple QCH files can be specified: https://gitlab.kitware.com/paraview/paraview/merge_requests/3540. I think it was a mismatch between the API input towards what happened towards the implementation.
set(paraview_qch "${ParaView_DIR}/Applications/ParaView/Documentation/paraview.qch")
Well, this works for a build tree, but will fail with an install tree. I’ve filed an issue here: https://gitlab.kitware.com/paraview/paraview/issues/19284
Thanks for the comments and filing the issue!
Making it clearer would be implicit if the tag would not be QCH_FILE but rather QCH_FILES - with an S at the end.
More generally speaking I would say that it makes a lot of sense to also include the ParaView filters/readers/writers… docs after including the plugins themselves into a custom application. And to make this possible, for me the most obvious way would be to make some “target” available after the find_package(ParaView) call, like ParaView::plugin_help or something, that could be added with the target_link_libraries. Which would basically assume that it exists already as a library.
For later on generating a similar help document for my own plugins I studied the generation process in ParaView - and of course I do not understand all the details yet! But the steps are as follows:
-
collect a list of all the server manager XMLs that contain documentation “snippets”
-
with some XSL transformation, extract the docs and convert it all into HTML which together with some additional files (index.html, table of content, CSS etc.) make up the help document
-
collect all the HTML and other files into one single QCH document
-
add this to a resource file (QRC) and use the Qt “resource tool” to convert this into some C++ with a lot of explicit binary stuff
-
compile and link into the application where the document can be accessed like a “file” with a “virtual path” starting with a “:”
My first attempt was to redo this entire process in my custom application and use the functionalities and macros for this purpose that are already existing in the Paraview build system. However this approach failed already with the fact that I did not get access to the list of server manager XMLs.
Ok, such a list could be “exported” through the find_package mechanism, but then still a lot remains to do because many of the ParaView build macros and functions are still “hidden” and would have to be cloned - and I do not know how much code I would have to “pull out” and duplicate for this to happen.
An advantage would be that it opens up the option to add help docs for own extensions directly into the original document and adapt it in all possible ways.
The approach that I finally realized is somewhat “hackish” - and of course I hate the fact that I am learning through the remark of Ben Boeckel that it would not work for installation: I was so far thinking that the QCH would not “live” any more in the installation tree anyway, being linked into the executable as a “resource”, but as I said initially: There are still many things that I do not understand yet!
The most comfortable but least flexible approach would be to make the plugin help doc available as a “target” that can simply be added with some target_link_libraries call and probably still an initialization function call in the main window constructor.
Making it clearer would be implicit if the tag would not be QCH_FILE but rather QCH_FILES - with an S at the end.
That’s what the linked MR does 
.
many of the ParaView build macros and functions are still “hidden” and would have to be cloned
Which ones? ParaView shouldn’t have anything private other than helpers (of which I don’t think any exist).
The most comfortable but least flexible approach would be to make the plugin help doc available as a “target” that can simply be added with some target_link_libraries call and probably still an initialization function call in the main window constructor.
Agreed. However, it will likely not make it until 5.8 (I’m headed out on vacation for a few weeks soon). I think getting projects to export their documentation will need some API design work and thought.
If that is the case - all the better: then it is “only” a question of understanding - which basically means “code digging”…
Because regarding my own project, I would actually prefer to generate one single documentation, following a bit the setup that I find in Applications/ParaView/Documentation/CMakeLists.txt. I think that I would somehow get this together - except that there is one variable that is available inside the ParaView build, but not inside a custom application:
paraview_server_manager_files
In that above mentioned CMakeLists.txt it can be assumed (and I tested it) that it contains a list of all the server manager XML files - like the naming says it already. These are somehow “collected” as a side effect of a number of other calls: no idea how I can get this variable out of the Paraview project build setup and into my own!
Btw and off topic here: I found a little bug in the ParaView setup files that is related to handling a splash screen image: in ParaViewClient.cmake(207) [referring to RC2] I had to change this line
":/${_paraview_client_NAME}/${_paraview_client_splash_image_name}")
into this:
":/${_paraview_client_NAME}/${_paraview_client_splash_base_name}")
Without this change, the pqInitializer::Initialize() function would look for a resource named <…>_splash.img while in reality the name of the resource would be <—>_splash - without the “.img” extension. (Of course the fix could have been done in a way that the naming of the splash bitmap is adapted to have the extension - only it has to match!)
All of the API should be documented. User-level documentation is necessary yet. Please keep a list of your path; I can use that as a guide to writing that docs. A list of holes in the API docs would also be nice to have.
This variable is the list of XML files that ParaView compiled into pvInitializerPlugin. Reusing this how other plugin docs get used would probably be the best way of doing that. That would also allow you to place your own front-matter instead of it talking about ParaView-the-application.
Yes, but they don’t exist outside the build.
Sounds reasonable. This code is only used by ParaView right now, so some assumptions may need shaken out yet. Please file an issue; I might get to it by tomorrow, but I’m not sure.
Thanks for your comments!
Actually I am ONLY dealing with build setup currently: I have my application already, and I am rebuilding the entire setup in order to port from v5.6 to v5.7 - and to me it looks like it is more straightforward to start from scratch and put the parts back together again. (However, the help system I have ignored so far - taking now the opportunity to add it together with the port: That way also the users will see some “positive effect” of it!)
Sorry, should have been more specific. They exist within ParaView’s build, but aren’t exported anywhere (build tree or install tree). The QCH file is generated, so it shows up, but the problem with the XML files is that you don’t know which ones ParaView is using even if you do go and rummage through the source tree for them.
I am rebuilding the entire setup in order to port from v5.6 to v5.7 - and to me it looks like it is more straightforward to start from scratch and put the parts back together again.
Yeah, the CMake stuff is mostly rebuilt, but it should be a much stronger base for future improvements and things should work together much better today.