In ParaView we have several places were we can create, save and run python scripts. This includes macros, python editor, and python shell.
In each case, only the client file system is accessible for the targeted script. This is a limitation for different workflow with a remote server. For instance:
connect ParaView to a remote server
do some analysis with data from the server
save a python state, for a latter pvbatch run
→ you can only save on your client filesystem, and thus you will need to manullay copy the script on the server.
The reverse is also true:
having a pvbatch script on the server
try to run it from ParaView client-server for debugging purpose
→ need to copy from server to local machine.
→ you cannot even just open it in the editor to look at its content.
Proposition
We would like to add features like run server script, load server script , save on server at the relevant places of the ParaView GUI.
Do you have any workflow that you would like to be covered ? Any point of attention to have in mind when implementing this feature ?
Generally I end up editing python trace files before using them, which seems to argue for them to appear on the client by default.
I do think having an option to save traces on the server would be useful for other use cases. For macros, it might be nice to create server-side macros that are stored there so they are available regardless of where you connect from. But that seems like a niche use.
In terms of the user interface, it would be wonderful to avoid adding lots of menu items but instead add a drop-down or other element to the file dialog to switch between client and server browsing.
No matter how you edit a script, it can be used in local mode or in remote client/server mode, far or not.
“Manual” copying of the scipt to FS client on the FS server is a bad idea since it promotes divergence.
Mathieu’s proposal to change, by clicking on a button, the view of the files accessible in the file management dialog box seems to me an excellent proposal. At the charge of ParaView to make the necessary temporary transfer.
With a special mention, if we could indicate (in one way or another) that the script file name passed as a parameter during the launch… is accessible only on a client FS.
We have a project to save data, screenshots, and state on the client or server this summer. Python scripts/macros were not considered, but it shouldn’t be difficult to use a common infrastructure including a common file dialog to do the same for them.
Thanks @cory.quammen. It looks like there is a consensus that this feature is needed and it may be expanded to more things, so a common architecture is needed.