search

visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
434 stars 111 forks source link

Audit/overhaul config file management and verbiage #4398

Open markcmiller86 opened 4 years ago

markcmiller86 commented 4 years ago

There are a variety of minor inconsistencies in how we do business with these files and features that we should consider addressing...

We have a lot of files related to behavior. These are described in detail in the File Locations section of the manual.

We also have a lot of related terms for these such as preferences, settings, configuration, session, etc.. Some of these words appear in the GUI and manual (e.g. preferences and settings which are the same thing) whereas we have a command-line option using the word config. So, there are inconsistencies in the way we name things.

Next, our notion of settings is a bit all too encompassing. Saving settings re-writes everything including host profiles, script tabs, color tables, etc. We probably need a way to categorize settings so we can say which category of settings to save (or ignore). During a save operation, presenting the user with a simple list of the items from the above bullets with check boxes next to them might be sufficient. Likewise, when we say -noconfig maybe we want to specify just some of the items above (e.g. -noconfig-profiles or -noconfig-colortables)

We have the ability to save things but don't have the ability to load them. Loading kinda sorta happens implicitly as part of a new session. Maybe explicit load could be useful.

Usage tracking files create a slew of files in ~/.visit. First, I don't think these files should be visible to the user. Maybe make them dot files??? Next, do we need one per version? Can't we do this in a single CSV or XML file of the form version-no: bool to indicate whether the version has been run instead of actually tracking the number of executions and having to write back to these files every startup. These are just raw ascii files too. I wonder same questions about the script.py files for command window tabs? Can't those all be in one file?

Finally, should we be a little more organized about structure of ~/.visit? I mean, we put host profiles in a sub-dir there named hosts but we don't put color table files in a subdir named color-tables or crash recover files in a sub-dir named crash-recovery, etc.

markcmiller86 commented 1 year ago

I pulled out of review state to have a conversation about but I also added deliberation label. This might be good discussion for an upcoming special topics meeting.