Best practice for a Preferences dialog..
-
Folks,
I'm an experienced developer though mostly not in Qt. I am curious as to what structure you would use for the data set in a preferences dialog. For example:
The prefs dialog is a long-lived object that can be queried for values, essentially globally;
The prefs dialog is short-lived, initialised from and changes another class/object that can be queried by other program code;
The prefs dialog is short-lived, initialised from code in the main program that reads prefs from other objects into it, displays the dialog, then writes changes back to other (multiple) objects;
The prefs dialog is short-lived, reads values from some global source - e.g QSettings - and writes back there. Other parts of the program always read from the same source;
and many others are I possible...
I have seen and implemented several of these and never felt that it was necessarily the "best" way. For example:
The first two ways both split many values (with types that are perhaps not otherwise global) into an object and away from the place they are primarily used. The second way, while seeming to split view from data "properly", also adds to the code that must be maintained although there may be offsetting advantages.
The third option just invites mistakes of failure to update the prefs setter/getter code properly with changes to the objects. The final way also suffers from that, but also means the translation from QSettings (etc) format to internal format is done in many places and can get out of sync.
Any thoughts?
-
Use a singleton to store settings at runtime, make it save stuff using QSettings when anything changes.
As to length of life of the dialog, it depends on how often it is being used, how complicated it is (if it takes a while to load, it's probably better not to delete it on close).
-
Thank you for that... I guess by singleton the point is essentially program-internal global state to match the QSettings global external state, so you would plump for options 1 or 2 in terms of my list (depending on whether the singleton was also the dialog).
I tend to use long-lived dialogs for things that a user might justifiably hope to see it in the same state time after time; Load and Save dialogs are a good example: you often want them to be in the same folder the next time. Conversely, I use short-lived dialogs for situations when there is no persistent state of that sort: messages are a good example of that, though there are borderline cases!
