We are working on an extension to the Favorites list in the file dialog, based on this issue. Basically the proposal is to add an entry to Favorites which doesn’t point to a specific folder, but looks up a path from an environment variable. This is particularly useful for connecting to different HPC machines that might use the same env var, like $WORKDIR, to point to the fast storage space available to the user.
Discussion so far says there aren’t any conventional env vars that should be hard-coded - does that match people’s experience?
My thought is that this would be implemented with a dedicated button next to the existing “+” button, and a dialog would ask for a label and the env var. Then, if the env var was found and pointed to a path that exists, that item would be enabled.
I think even if there is some standard env variable (which I’m not aware of) option 2 is more flexible so we should go with that. Ui seems seems reasonable
I’m not sure I see the point of this. Since any folder can be added as a favourite via a pop-up menu, when a folder is selected, why is that not sufficient?
The only problem I see is that adding a local folder as a favourite does not add it to the “Favourites” header in the file explorer dialog. Instead it appends it to the bottom of the folder list (in my case under Windows network).
So the user should edit an environment variable rather than editing the settings in Paraview? Why? Is it because there is no configuration file for the Favourites settings that can be updated with a text editor?
That’s currently how some HPC users do things across different machines, and the idea is to support that use case, not change how settings are handled in ParaView for other favorite directories.
For my use case, $WORKDIR is an environment variable pointing to my work directory on several different HPC machines. The actual path is different on most of these machines and as is the case with HPC machines there are hundreds if not thousands of users. All of these users have $WORKDIR=/a/b/c/username. If you’re one of the lucky, alphabetically superior ones (e.g. username starting with “a” instead of “y” or “z”) then you don’t need to scroll through thousands of names to get to your work directory. Otherwise you have yet another pain point for getting to your work directory.
The other thing is that I don’t have to remember what a, b, c in the above example is. Also, new machines coming online will also use this $WORKDIR env convention.
@Andy_Bauer Does your organization customize the ParaView settings on install? If you do…
An alternate implementation is to add a section to the Misc settings, which is a list of labels and env-vars, which would then be added to the Locations section. This is essentially how the “Home” directory works on Linux - it looks up the value of getenv("HOME"). Thanks @todoooo for the idea prompt…
The env-var value would be looked up each time the File dialog opened, and would show a warning icon if the directory doesn’t exist (just like Examples does now, for anyone running PV from a local build)
Does that sound better/worse that the icon in Favorites? It’s more hidden, but that seems appropriate, since it’s a specialist feature for connecting to multiple remote machines.
We don’t customize ParaView settings on install, at least not currently, but I suppose it could be done.
Are we talking about the install on the server or the client? I’m just worried about an inconsistency there.
Is there an issue with this being available through an installation mechanism as well as through users being able to add the mechanism through settings?
Nope, there’s no issue - I was thinking that this would be a clear win if you were already customizing settings. This would be the client install - it only affects the user sitting in front of the client app. Customizing a setting is still pretty easy to include in a “getting started” checklist for your site, what do you think?