ParaView Settings 2.0: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
(Created page with "=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 w...") |
|||
| Line 8: | Line 8: | ||
# 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. | # 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. | ||
# Qt state such are window size, position, dock panel visibilities and positions etc. These are not explicitly controllable from any user interface. | # 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: | |||
# Preserving settings across versions is not possible. User looses all his preferences when he updates to a newer version. | |||
# Proving system wide configurations for sites/installations is not possible. Each user is on his own. | |||
# 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. | |||
# 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. | |||
# Everything is accessible only via Qt-based applications. Non-Qt based applications like pvbatch, pvpython are left in the dark. | |||
Revision as of 01:46, 5 December 2013
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
- User specific application preferences such as default view type, default remote render threshold. All of these preferences are settable using the Edit | Settings dialog.
- 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.
- 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:
- Preserving settings across versions is not possible. User looses all his preferences when he updates to a newer version.
- Proving system wide configurations for sites/installations is not possible. Each user is on his own.
- 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.
- 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.
- Everything is accessible only via Qt-based applications. Non-Qt based applications like pvbatch, pvpython are left in the dark.
