Settings
-
If you have a program in which many of the core functionality is determined by a settings dialog, what would be the bast way to manage?
Read the value from the widgets themselves and then save them to QSettings on close, or save to QSettings immediately whenever the settings are changed and then read from QSettings?
-
I would try to determine what kind of changes are to be done when you change one setting, i.e. if changing the only setting is too heavy and needs processing huge amount data then I would rather save settings on accepting of that dialog. On the other hand, dynamic adoption to changed settings is also cool and if it is not heavy then I would apply them immediately on setting change.
-
[quote author="MTK358" date="1286455634"]But basically read from QSettings, not the settings widgets, in your program, right?[/quote]
I would read from QSettings at startup and read from settings dialog on accepting the modified settings during runtime.
[quote author="MTK358" date="1286455634"]And for dynamic adoption of settings, should I create a slot for each widget that updates QSettings?[/quote]
Either slot, or a regular function. Pick the one you like and prefer. I would go with a regular function. But that's my choice and I might be wrong.
-
bq. I would read from QSettings at startup and read from settings dialog on accepting the modified settings during runtime.
So you would actually read the values of the widgets? Also, is it a good idea to delete the settings dialog when it's closed?
bq. Either slot, or a regular function. Pick the one you like and prefer. I would go with a regular function. But that’s my choice and I might be wrong.
How is a regular function supposed to be called every time a widget is modified?
-
[quote author="MTK358" date="1286457849"]So you would actually read the values of the widgets? Also, is it a good idea to delete the settings dialog when it's closed?[/quote]
Yes, I would read from the widgets, and here is sample source code so that we both understand it right and talk about the same.
@void OptionsDialog::accept()
{
// read params
Type1 param1 = lineEdit->text();
Type2 param2 = scrollEdit->value();// here we store parameters values saved in param1, param2 settings(...., param1); settings(...., param2);// dynamic adoption to the changed settings
emit param1ChangedSignal(param1);
// or (if you have a handle for this widget
myWidget->switchState(param1);
}@And as for deleting the dialog on close, then I would definitely do that with options dialog.
[quote author="MTK358" date="1286457849"]
How is a regular function supposed to be called every time a widget is modified?[/quote]For instance, see the source above.
-
I don't understand your "dynamic adoption".
My idea of dynamic adoption is no Apply or OK button, the settings are adopded right away as you check the checkboxes, move the sliders, etc.
If you ever used GNOME (a desktop for Linux written using the GTK+ toolkit) you will know what I'm talking about. Their settings dialogs don't even have "Apply" or "OK" buttons. Personally I love that and wish all settings dialogs were like it. :)
-
MTK358: I do like instant apply if there is a good undo mechanism. Unfortunately that is often not the case and then the option to change something, maybe preview it somehow, before committing to the new settings by hitting "Apply" is nicer in my opinion.
-
I used GNOME and I know what you are talking about :) Precisely the absence of Apply button made me feel uncomfortable, honestly.
You may call me a fan of Apply button. Some changes might be done by mistake, or maybe I changed my mind and don't want to do that changes anymore. So I want to control that. -
And I must agree (mostly) with lyuts, I don't like that there isn't at the very least, an ok button, because clicking that I know that the settings will take effect, rather than just hitting the close button. I would advise at least using an ok button so that users are more familiar with it. (if all else put a finish button as well as a close button :P even if the changes are applied dynamically)