Ken,
I have never minded having two different “open” dialogs, one for data and one for state files. Why not just keep both? Works well, and is simple to describe as is now…
Two different dialogs to open different kinds of files is weird behavior. Most other applications only have one, and infer the correct operations from the file extension or something similar. As far as I understand, the only reason we do things differently is because we are managing file systems on two separate machines. You are absolutely correct, it’s not that hard to understand, once you get used to it, as we all have. However, there is a reason that I had to set up a desk in a cubicle across the hall from Boonth for three months when I first started working with Paraview, because I couldn’t get anything to work without a lot of hand-holding.
Ensight has the same sort of issue, and I have had to walk users through this exact difference:
“Why can’t I open context files (ensight .pvsm equivalent) from the GUI? I can only open them from the command line.” The answer was that you had to use a different menu option to load a context file, just like we do with state files, but it was easy to tell that the user thought this was confusing and dumb. This kind of thing contributes to the overall bad experience that new users have when interacting with Paraview without a readily available, in-person, mentor.
There may be technical reasons that this is much harder to do than it seems, but I think the usability benefits are quite significant.
As we’ve already mentioned, we also have ParaView users who wish to store their state files next to the data - on the server. Having this option is desirable.
-Aron
I’m one of those who has discussed this functionality with Aron.
The typical workflow for users at my company is to connect to a Linux-based server from a Windows-based client. So when they save state files, not only do they have to copy them over (or go through mapped network drives) but on their own, the data paths in the state file are in a completely different file-system than that of the machine the state file is (by default) saved to. That means these state files on their own are completely useless. That to me just doesn’t make sense.
For this reason I think the state files should live where the data lives. If one wanted consistency I suppose this logic would have to be extended to traces and Run scripts as well. I would personally advocate that macros live server-side as well (so that all users could reference them from a central location) but I admit it’s probably better to leave those client-side.
Perhaps the ability to save state files/traces/scripts to the server could be a power-user option, set by an environment variable or a command-line flag? I would prefer environment variable so that I could set it for all users.
1 Like
Edit: The reply didn’t end up where I expected. Adding appropriate context.
I really think the answer here is to have a single Open/Save dialog, with a drop-down menu to choose between client and server file systems for both operations. It would use the same interface for everything. It should probably throw a warning (or an error) if the operation is going to result in the transfer of a large amount of data, with the precise value set in the Preferences window, just like remote rendering settings are.
I think that there should be default choices made, and I’m totally fine with keeping those to what our current behavior is, but the user’s choice should be persistent across sessions (like most of our settings are).
There are just too many different use cases for us to find one that makes everyone happy. It depends on the client hardware, the availability of server time, the relative size of the data compared with the bandwidth of the connection, and so on. Someone with a powerful workstation client and limited server time will want to save large data products locally, while someone else who works on several different client machines and a visualization cluster will want EVERYTHING on the server.
1 Like
Just curious where KitWare has landed in regard to this discussion, most specifically in regard to the filesystem used to save state files.
Obviously there were not any changes made for the 5.9.0 release, but I’m just wondering if there are any changes to be expected in the future.
I still stand by my preferences/suggestions, and I believe I articulated/defended my arguments well so I don’t think it’s of any value to reiterate them.
I’m ready to accept whatever decision has been made without further debate, just wondering if there’s any news to share with my userbase 
1 Like