PV Custom application version 5.7: Where are the PV plugins?

[ben.boeckel (Ben Boeckel (Kitware))]

@cobo

If that is the case - all the better: then it is “only” a question of understanding - which basically means “code digging”…

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.

@cobo

except that there is one variable that is available inside the ParaView build, but not inside a custom application:

paraview_server_manager_files

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.

@cobo

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!

Yes, but they don’t exist outside the build.

@cobo

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!)

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.

[cobo (Cornelis Bockemühl)]

Thanks for your comments!

@ben.boeckel

Yes, but they don’t exist outside the build.

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!)

[ben.boeckel (Ben Boeckel (Kitware))]

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.