ParaView Settings 2.0

As things stand

As a first pass, I am going to ignore view-specific settings and only focus on application settings.

We currently have a mechanism for global application wide settings that relies on Qt's QSettings which saves out a ini file in the user's home directory. There are several things saved in this ini file

1. User specific application preferences such as default view type, default remote render threshold. All of these preferences are settable using the Edit | Settings dialog.
2. User specific application preferences for components across the application, such as default color table, default render view background color, state of advanced button on properties panel, etc. There options are not accessible from the Edit | Settings dialog, but are scattered throughout the application UI.
3. Qt state such are window size, position, dock panel visibilities and positions etc. These are not explicitly controllable from any user interface.

Right out of the gate there are several problems with this approach:

1. Preserving settings across versions is not possible. User looses all his preferences when he updates to a newer version.
2. Proving system wide configurations for sites/installations is not possible. Each user is on his own.
3. It's unclear what is configurable and what isn't. There's no model followed: I can control default color table, I cannot control default color legend placement or font.
4. The keys and values used for items in the config file is very loose. No specific naming convention or pattern. In general, though the file is ASCII, it is hardly human readable or processable.
5. Everything is accessible only via Qt-based applications. Non-Qt based applications like pvbatch, pvpython are left in the dark.

Now the user interface. The application settings dialog itself is a dialog split into multiple pages and sub-pages with a lot of options. There are several problems with this:

1. Discoverability: it's not easy to know what's available unless you know what you're looking for.
2. Searchability: it's not easy to know where a particular option is available.
3. Comprehensibility: all options are very developer specific with not much information in the dialog to know what they are or how they affect things.
4. It's not easy to know what's at default , what has been changed or modified by the user.

Inspirations

Sublime Text

• Use a hierarchical approach to settings configuration files allowing application-specific, site-specific, and user-specific configurations files.
• These files are simple JSON text files allowing easy grouping and clustering of options.

Chrome

• Flat settings page with simple and advanced properties that is entirely searchable.
• Page layout allows for grouping and information text blurbs that make it easier to search and understand the options available.

Random Ruminations

• Move "settings" infrastructure to servermanager (SMSettings). Qt application will still use Qt's QSettings for saving Qt state like windows size etc. but for ServerManager releated state, we use SMSettings. Now pvbatch/pvpython can use them.
• We can provide a mechanism for pvbatch/pvpython to use a custom settings files on command line (or through API) allowing sharing of settings files for insitu. Thus making pvpython and ParaView Qt gui produce similar results for similar Python scripts that are not excruciatingly verbose.
• Any proxy/property's value can be set in SMSettings. Whenever a new proxy is created, after loading the compiled in XML default, ProxyManager will look at SMSettings to load defaults from settings. These are not data-dependent defaults, but similar to hard coded default values in the ServerManager XML configurations. Now we can easily support saving of various fonts/colors/etc in settings without any issues. If we allow users to look at the raw JavaScript to edit values, advanced users can manually tweak them as well.

Things to look at

1. Sublime Text Settings
2. Boost Property Tree
3. JSON CPP

Design

Things to remember

1. Remember to keep IO accesses to a minimum. For checking existence of configuration files, see if we can use the "fastest" API to check for the file, if applicable.
2. In pvbatch-symmetric mode (and in co-processing mode), the configuration files should not be read on all processes, only the root node should read it and then send it across to satellites.
3. There should also be a mechanism where the configuration files are not read at all, instead one can use some API to load the configurations.
4. When saving python state/trace files, there must be mechanism to save all "applicable" configuration values in the generated python state/trace files.