Plugin with only property widgets

Development
1

Still struggling with building a lot of plugins and modules with the new version 5.7 build setup.

The current construction site is a plugin that contains a number of property widgets, plus one “decorator”, to be used by a number of other plugins. The current status is that everything builds, all the plugins are loaded (not sure if they are working though…), but the PropertyWidgets plugin generates an error message during loading:

found /ultrabay/Development/AthosGeoView/Binaries/Release/bin/PropertyWidgets.so
appDir: /ultrabay/Development/AthosGeoView/Binaries/Release/bin/plugins
Attempting to load: /ultrabay/Development/AthosGeoView/Binaries/Release/bin/PropertyWidgets.so
Loaded shared library successfully. Now trying to validate that it’s a ParaView plugin.
We’ve encountered an error locating the other global function “pv_plugin_instance” which is required to locate the instance of the vtkPVPlugin class. Possibly the plugin shared library was not compiled properly.
vtkPVPluginLoader (0x2cb7c70): Not a ParaView Plugin since could not locate the plugin-instance function.

I found that a function pv_plugin_instance exists in a file named PropertyWidgetsPlugin.cxx.o, but indeed it does not exist in the final shared library PropertyWidgets.so. Other plugins have that function in both the .cxx.o and in the .so file, so there is definitely something missing. This is also obvious if I generate a ninja -v log: Other plugins are linked with their .cxx.o file, but this one is not.

Now the question is how to get there?

My starting point was to follow the example of the property widgets example plugin. This has a paraview.plugin, an *.xml and a CMakeLists.txt file that specifies an “xml only” filter (using the existing “shrink” filter from VTK). In my case it is property widgets only, so also no xml file. But with that, the final paraview_add_plugin call in the CMakeLists.txt complains about having nothing to do, so I changed the example in such a way that I added a “module”, like with most of the other plugins. The module contains now all the code, and the paraview_add_plugin refers to that module - like with other filter plugins with code.

With this, both the CMake run and the ninja build are running through smoothly, but that one link command is not properly done. It is only

/usr/bin/g++ ... -o bin/PropertyWidgets.so .../PropertyWidgets_autogen/mocs_compilation.cxx.o ...

While the same command line for other plugins would be

/usr/bin/g++ ... -o bin/WhateverPlugin.so .../WhateverPlugin_autogen/mocs_compilation.cxx.o .../WhateverPluginPlugin.cxx.o ...

Now the big question is: I know what is to be done at the “build” level, but how can I tell this to the Paraview/CMake build system?

  • do I need some kind of dummy filter *.xml to make it happen? But it would then show in the plugins list and confuse the users. If the xml is the decisive factor I could of course also do some “ugly hack” and append all the property widgets to one of the “real” filter plugins that I am using - and hope that the other filter plugins that need the property widgets can find them there.

  • or is there maybe any additional plugin generation command that I need to apply for this to happen?

Already the paraview_plugin_add_property_widget command brought me out of the last endless loop, between module that does not load and plugin that does not properly build.

2

Things that I consider as “learnings the hard way” so far:

  • where in the past a “plugin” was typically a shared library file with plugin wrapper code, plus custom code (or only an xml specification), there are now normally two shared libraries: a module (with the custom code) and the plugin itself with only some wrapper and/or loader code

  • a plugin needs either an xml for specification (and then it will end up with only one shared lib) or a module, or both

  • normally a plugin does not have additional custom code, but in the example of the property widget, the widget code is not in a module but in the plugin itself

  • it is possible to have also plain modules without a plugin, containing code that can be used both in the main program or in the plugins. I did not find out yet at what time these modules are linked in and how

3

The struggle is going on!

Rebuilt again the project setup, and now I added one of the property widgets directly into the code of one of the filters using it. I had done that in the past already without succes, but now I used that newly “discovered” function

paraview_plugin_add_property_widget()

Which looks like it should do the job - or not?

But after all that reworking the effect is only that now also that filter is reported as having no “pv_plugin_instance” function any more…

So the HUGE QUESTION is remaining:

HOW CAN I ACHIEVE THAT A PLUGIN REALLY GETS THAT pv_plugin_instance FUNCTION??

There must be a key to this, but so far the behaviour is completely arbitrary and bizarre for me!

The good thing about automatisms is always that “everything comes automatically”. But if they do not work it is just plain horror…

4

It’s working now - finally!

And it was just a stupid mistake: in the paraview_add_plugin() call I had an INTERFACE instead of an UI_INTERFACE…

I did not figure out yet why this did not generate an error message (because INTERFACE does not seem to be a valid key), but for the moment I am first of all happy that I am so far now!

1 Like
5

A lot of the arguments are multi-valued, so when INTERFACE is seen as a not-keyword, it is tossed on the list of arguments to the previous multi-value argument (if it is such). Since it is also a CMake keyword in various places, CMake may eat it up if that argument value is used in one of those contexts.