Ok,
So, I've prototyped the user settings dialog. In so doing, I've actually built a class which (somewhat) dynamically generates user settings widgets.
Here's a sample using just the four settings thus far identified for the editor:
- User settings prototype
There are some basic formatting constraints I imposed in an effort to keep the code as manageable as possible. The basic rules are pretty simple:
1. Property widgets are right-aligned with corresponding labels left-aligned.
2. Each property is encased in a group box whose title bears the property's name in bold.
3. Each tab bears the name of each property section.
- Widget component descriptions
The few settings we have identified for the editor actually gave me a chance to design for a fairly complex layout. For example, in many cases, a property will simply consist of one widget (or a group of widgets - like radio buttons) to manage the property value. The "Undo Stack Size", "Maximum Top-Level Windows", and "Re-Use Sub Windows" properties demonstrate this.
However, the "Default Window Size" property has two additional complexities: a "composite widget" nested within a "toggle widget group"
A "Composite Widget" is really a way to combine two separate properties in the same group. Technically, it consists of more than one widget which may represent more than one property. For example, suppose in the settings file there are two screen settings: WindowWidth and WindowHeight. There are two ways in which the user can specify these two properties - by choosing a default, pre-defined resolution, or by specifying the width and height separately.
Internally, three property widgets are created - a combo box for the pre-defined resolutions, and two line edits for the custom resolutions. The line edits are combined into a composite widget, and then the composite widget and the combo box widget are nested together on the right side of the "toggle widget group".
Note that I wrote the toggle widget group code so that a radio button or check box can be used for the toggling widget. Also, I've allowed for vertical / horizontal orientations of groups, widgets and labels at every level. Further, additional properties could easily be added below these initial ones, or alongside in a second column.
Notes on updaing / saving properties:
Using this design should help simplify linking widget changes to actual application variables and saving property values, as well as ensuring corrupted settings files are corrected.
Regarding saving settings, I do not intend to do any file writing until the user settings dialog is closed (via the missing "done" button). Property changes will update the application behavior immediately, but I felt it would be best to defer file writing until the user was done making changes altogether.
Further, I'm using the widgets themselves as the settings containers. That is, once the settings are loaded and the settings dialog is populated, the loaded settings are dumped. After the user makes whatever changes they feel necessary, the settings file is written by pulling values directly from the property widgets. This ensures that a corrupted settings file is corrected the next time the user attempts to edit it. (In fact, it could be triggered automatically and used to check for corrupted settings files, if that was ever necessary).
Note that I've written a wrapper class for the property widgets so that the property names in the settings file do not need to match the names which are displayed in the settings dialog. This is necessary for obvious reasons like in the case of the composite / toggle widget used to manage window size...