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.
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.