Saving state of nested widgets

[SeanM]

My application has the following setup: on the main window (QMainWindow), I've got a tabbed widget (QTabWidget), which the user can configure to have 1-N tabs open. On each tab is a container widget which the user can configure to hold 1-M plot items (QwtPlot). While using the application, the user can choose what data fields are displayed on each plot from a list of available data feeds. This allows the user to create a custom setup of number of tabs, number of plots per tab, and custom data on each plot.

I'd like to be able to allow the user to be able to export/import that information (number of tabs, number of plots per tab, subscribed data fields per plot), so that they can create repeatable configurations.

There's two requirements for this:

1. When the user closes the application, the current state is saved and is then restored on the next application launch
2. The user can export the setup explicitly to a file and restore the state from a file. For example, the user can export one setup as "MySetup1" and export a different setup as "MySetup2", then read back in "MySetup1" and have the settings go back to that setup.

So the first question is: should I do all this with one (or maybe two?) QSettings objects? The application will be running mainly on Windows, so in requirement #1 (saving/restoring previous state), the settings should be stored in the registry, which leads to creating a QSettings object that is using QSettings::NativeFormat. But then for requirement #2 (import/export of custom setups), I think I need to use a second QSettings object created with QSettings(const QString & fileName, Format format, QObject * parent = 0) with Format set to QSettings::IniFormat.

The second question, assuming QSettings is the right class for this, what's the correct way to save out this info? I think I need to do something like the following:

settings->setValue("NumTabs", ui->tabPlotWidget->count()); 
for (int i=0; i < ui->tabPlotWidget->count(); i++) 
{
    settings->beginGroup(QString("Tab") + QString::number(i));
    settings->setValue("NumPlots",ui->tabPlotWidget->widget(i)->plotCount());
    for (int j=0; j < ui->tabPlotWidget->widget(i)->plotCount(); j++)
    {
        settings->beginGroup(QString("Plot") + QString::number(j));
        // write out all plot information
        settings->endGroup(); // end the "Plot#" group
    }
    settings->endGroup(); // end the "Tab#" group
}

settings->setValue("NumTabs", ui->tabPlotWidget->count()); 
for (int i=0; i < ui->tabPlotWidget->count(); i++) 
{
    settings->beginGroup(QString("Tab") + QString::number(i));
    settings->setValue("NumPlots",ui->tabPlotWidget->widget(i)->plotCount());
    for (int j=0; j < ui->tabPlotWidget->widget(i)->plotCount(); j++)
    {
        settings->beginGroup(QString("Plot") + QString::number(j));
        // write out all plot information
        settings->endGroup(); // end the "Plot#" group
    }
    settings->endGroup(); // end the "Tab#" group
}

To copy to clipboard, switch view to plain text mode 

And then do the reverse for reading it back in... Any better ideas?

[anda_skoa]

You can use any kind of file format, even a custom one, if you find something more applicapable than key value pairs (QSettings),

The first requirement just implies that the application knows which filename you are using for the restore file.

Cheers,
_

[SeanM]

True, I guess I should have been a little more specific. On the surface, it seems like QSettings fits the bill for what I'm trying to do, I guess I just wanted to hear arguments one way or the other about benefits/limitations choosing QSettings over a custom file format.

[anda_skoa]

If using QSettings doesn't make the code awkward then go for it.

I would still recommend to use the same format for both explicitly saved state as well as end-of-program state, e.g. with QSettings always use IniFormat, and just remember the file name for the end-of-program file using native format.

This way you have exactly the same code paths, don't have any difference in backend capability and can easily switch to a different presistence technology if QSettings becomes too limited.

Cheers,
_