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.

This proposal tries to come up with a design that addresses some of these issues.