User Configuration

Requirements

• Store per-user configuration data
  • Window size/position
  • Dockwindow size/position
  • Server resources (e.g: recently used files)
  • Server configurations
  • Custom filters
• Store per-site configuration data
  • Server configurations
  • Custom filters
• Make it easy for users to share/exchange configuration data
  • Server configurations
  • Custom filters
• Store arbitrarily-complex data - no limits on the size/complexity of data stored

Current Implementation

The current implementation stores configuration data in arbitrary ways:

• Per-user window/dockwindow size/position aren't stored at all.
• Per-user recently used files and server configurations are automatically stored using QSettings.
• Per-user custom filters can be explicitly saved/loaded to the filesystem as XML files. Otherwise, they are lost.
• Per-site server configurations are stored in a file located in the same directory as the ParaView3 client.

On Win32, QSettings data is stored in the system registry, which severely limits the size of individual keys to 16K or less.

Alternatives

Option 1: use QSettings for everything

• Store all configuration data using QSettings.
• QSettings can be forced to use the filesystem for storage on all platforms, eliminating the limitations on data size when using the Win32 registry.
• Allow users to explicitly save & load individual bits & pieces of configuration data, to facilitate sharing.

QSettings stores per-site and per-user data that are loaded in order as follows:

The following files are used on Unix and Mac OS X:

   1. $HOME/.config/Kitware/ParaView3.0.ini
   2. $HOME/.config/Kitware.ini
   3. /etc/xdg/Kitware/ParaView3.0.ini
   4. /etc/xdg/Kitware.ini

On Windows, the following files are used:

   1. %APPDATA%\Kitware\ParaView3.0.ini
   2. %APPDATA%\Kitware.ini
   3. %COMMON_APPDATA%\Kitware\ParaView3.0.ini
   4. %COMMON_APPDATA%\Kitware.ini

All of the above files use an "INI-like" file format (there isn't a formal standard for INI files). Following is a real-world sample generated with a patched paraview_alpha:

[General]
ServerResources=builtin:/C:\\src\\ParaView3Data\\Data\\multicomb_2.vts, builtin:/C:\\src\\ParaView3Data\\Data\\multicomb_1.vts, builtin:/C:\\src\\ParaView3Data\\Data\\iron protein.vtk, builtin:/C:\\src\\ParaView3Data\\Data\\multicomb_0.vts, builtin:/C:\\src\\ParaView3Data\\Data\\can.exo, builtin:, builtin:/c:\\src\\ParaView3Data\\Data\\disk_out_ref.exo

[Servers]
foo="<Server name=\"foo\" owner=\"user\" resource=\"cs://localhost\" >\n <CommandStartup>\n  <Command exec=\"asdfaf\" timeout=\"0\" delay=\"5\" >\n   <Arguments/>\n  </Command>\n </CommandStartup>\n</Server>\n"
foobar="<Server name=\"foobar\" owner=\"user\" resource=\"cs://localhost\" >\n <CommandStartup>\n  <Command exec=\"a;lsdkfja;sldfjasdl;fj\" timeout=\"0\" delay=\"5\" >\n   <Arguments/>\n  </Command>\n </CommandStartup>\n</Server>\n"
foobarbaz="<Server name=\"foobarbaz\" owner=\"user\" resource=\"cs://localhost\" >\n <CommandStartup>\n  <Command exec=\"ls\" timeout=\"0\" delay=\"5\" >\n   <Arguments>\n    <Argument value=\"-l\" />\n    <Argument value=\">\" />\n    <Argument value=\"myfile.txt\" />\n   </Arguments>\n  </Command>\n </CommandStartup>\n</Server>\n"
localhost%20%28reverse%20-%20with%20port%20selection%29="<Server name=\"localhost (reverse - with port selection)\" owner=\"user\" resource=\"csrc://localhost\" >\n <ManualStartup/>\n</Server>\n"
localhost%20%28reverse%29="<Server name=\"localhost (reverse)\" owner=\"user\" resource=\"csrc://localhost\" >\n <ManualStartup/>\n</Server>\n"

Option 2: Use filesystem storage for everything

• Store all configuration data in a file hierarchy somewhere.
• Document the file hierarchy to facilitate sharing.

Option 3: Hybrid QSettings/filesystem storage

• Store some configuration data using QSettings.
• Store data that might be shared in a file hierarchy somewhere.
• Document the file hierarchy to facilitate sharing.

Pros and Cons

Option 1 requires zero effort for serialization code, since it is simply a matter of using the QSettings API already provided. It provides a consistent, well-documented mechanism for handling per-site settings that are automatically overridden by per-user settings. Extra coding effort may be required to provide user interface for loading & saving data that is shared between users, but the scope of that code should be minimal, assuming that configuration data can be stored in a consistent file format (such as XML) in both cases. When loading data, sanity-checking can be used to prevent undesirable conditions (such as two server configurations with identical names).

Option 2 requires effort to design and implement custom storage to the filesystem. Since users will be required to navigate the filesystem to share configuration, it will have to be documented. In the process users may accidentally alter their configuration in unwanted ways - there are no opportunities to do sanity checking when the data is manipulated at the filesystem level.

Option 3 seems like the worst of all worlds since it requires all the effort of option 2, *and* leaves the door open for conflict over which system (QSettings or custom) to use for a given piece of configuration data.

Open Issues

Would like to confirm that XML data stored in a QSettings key doesn't introduce any unexpected problems with character escaping, etc.