Looks like a solution was found - in still another direction than what I initially guessed.
During my internet research also regarding “wrapping”, I came to a 5 years old problem that I had completely forgotten, but at the time it was myself who initiated it: How to ensure that "client-server wrapping is properly initialized"?. So it was partially my own explanations in that thread that brought me back on track also this time! So again I am going to explain the two problems together with their current solutions.
-
This is the problem that I solved by undoing a little change in vtkModule.cmake, which caused CMake to terminate early due to no headers found for a plugin. This could be solved by simply undoing a change that Ben Boeckel has made about one year ago: https://gitlab.kitware.com/vtk/vtk/-/commit/cf774eac9efcad39ae0893c2fbcfcac561e43abb. From his comment (“There’s nothing wrappable here anyways.”) I conclude that there was no “urgent need” for this step, but simply it looked more logical like that. Which may be true, but I cannot judge this. However, in my case this triggered a side effect in the case of a plugin that had no other headers left then, and via some other steps the vtkModuleWrapClientserver.cmake terminated with the message that I had initially: No modules given could be wrapped. I saw that also for all the other plugins one less header was attached, but whether this would have caused any trouble or not I cannot judge because at the end I could not build anything because of this error!
-
That same plugin was also in the core of the second problem: Start the successfully built application, generate a “block model” with some specific “source” within my application (…from which I conclude that “regular” plugins with “filters” do actually build AND run…), but on pressing “Apply”, the program crashed with the message that I cited above: symbol not found. Which was the constructor of a property widget class which should have been generated in the “Display” panel. Meaning: a plugin with only property widget code and no “filter” was not correctly built.
It turned out that it was exactly the same plugin that caused already the trouble 5 years ago: the vtkWrapHierarchy seems to be unable to parse headers that refer to Qt widgets, always complaining about “syntax errors” that are not really there, with no way to change the code in such a way that the tool is happy and still also the C++ compiler.
At the time (5 years ago) it turned out that the key lies in the CMakeLists.txt file for the module code to be embedded in the plugin. This was the initially intended way of writing it in that file (with parts omitted that are irrelevant for the problem):
set(classes
widBlockModelParam
widCategoryValue
widCellArrays
widMultiSelsAndValues
widSamplingParam
widSelectionIds
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
CLASSES
${classes}
SOURCES
...
But this is is exactly what caused the trouble at that time. The solution was then finally:
set(classes
widBlockModelParam
widCategoryValue
widCellArrays
widMultiSelsAndValues
widSamplingParam
widSelectionIds
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${classes}
${ui_files}
${qrc_files}
...
This worked at the time, but obviously not any more with the current PV version 5.13.1! I saw now that “strange” code, having completely forgotten the reason for it (lack of good commenting…), so I changed it back: I was getting again the error messages from the vtkWrapHierarchy tool that “hates” Qt widget headers. (And after an internet search I hit that old “discourse” thread…)
From this I knew that it is all about the headers, while the sources are required to generate some code at all. The format with class names being passed as SOURCES probably has the effect that for each class, both a .cxx and a .h are added - and as long as the .h files were not added in a HEADERS section (which would be the effect of putting that same list into a CLASSES section), everything went fine with PV 5.12.0.
But not with 5.13.1! However, changing the above to the following at least generated code that did not crash any more:
set(sources
widBlockModelParam.cxx
widCategoryValue.cxx
widCellArrays.cxx
widMultiSelsAndValues.cxx
widSamplingParam.cxx
widSelectionIds.cxx)
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${sources}
${ui_files}
${qrc_files}
...
Only one little problem remained: The headers disappeared now also from the QtCreator display! But finally with the following also this could be solved:
set(sources
widBlockModelParam.cxx
widCategoryValue.cxx
widCellArrays.cxx
widMultiSelsAndValues.cxx
widSamplingParam.cxx
widSelectionIds.cxx)
set(private_headers
atgShowOnlyIfNewAttribute.h
widBlockModelParam.h
widCategoryValue.h
widCellArrays.h
widMultiSelsAndValues.h
widSamplingParam.h
widSelectionIds.h)
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${sources}
${ui_files}
${qrc_files}
PRIVATE_HEADERS
${private_headers}
...
So basically in some way these widget classes are now “half private” 
Now I learned that I will have to write good comments into my code - and go on testing…
What I know now is the fact that my plugin with property widgets needs “wrapping” only in order to be somehow considered a “proper plugin” that can be loaded and used from other plugins and code. For any decent technical reason, “wrapping” would not be required at all, because these widgets only appear on the client, not on the server side of the application.
And even though it may be true basically what Ben Boeckel is writing: “nothing wrappable there…”, plus the fact that the entire thing also does not need any “wrapping”, changing his code line back to the “unlogical” form that was there before is for me currently the only way to “make it happen” again.
If anybody now can point me to some example or tutorial that tells me how to achieve that without “funny workarounds” I would probably simplify my code accordingly. If not, I am for the moment glad I found some solutions that works “somehow”.
