Yes, sounds interesting.

So the settings would then get saved into the QByteArray, right?
Hm, would that mean that one could still use this in some human-readable way together with QSettings? (so that the same method that generates the settings saving could also feed into QSettings?).

Right now we already have some kind of readSettings/writeSettings-implementation in QtMainWindow of the Marble application. Maybe you can use that to create this method?  

What do you think?

QByteArray and QSettings work together well, so the settings code in the Qt main window of marble could easily make use of that method as well (and provide most of its implementation). I think that the human readability might suffer a bit from the QByteArray conversion however. I'll check that in the next days.

The reason I'd favour QByteArray is that it should work equally well with KConfig (judging from the apidocs). I'll try to make up a patch if you agree.

> I'll try to make up a patch if you agree.

That would absolutely rock! I'm looking forward to it.

Created attachment 31254 [details]
marble-state.diff

Here's an initial version for discussion. It does not use the version yet and ignores default settings, but that can be added easily later. I'd like some input on the streaming format first -- the settings group written by Marble's QtMainWindow becomes this with the patch:

[MarbleWidget]
state=@ByteArray(\0\0\0\x5\0\0\0\x14\0p\0r\0o\0j\0\x65\0\x63\0t\0i\0o\0n\0\0\0\x2\0\0\0\0\0\0\0\0\x10\0m\0\x61\0p\0T\0h\0\x65\0m\0\x65\0\0\0\n\0\0\0\0L\0\x65\0\x61\0r\0t\0h\0/\0o\0p\0\x65\0n\0s\0t\0r\0\x65\0\x65\0t\0m\0\x61\0p\0/\0o\0p\0\x65\0n\0s\0t\0r\0\x65\0\x65\0t\0m\0\x61\0p\0.\0\x64\0g\0m\0l\0\0\0\x10\0h\0o\0m\0\x65\0Z\0o\0o\0m\0\0\0\x2\0\0\0\vX\0\0\0\x1a\0h\0o\0m\0\x65\0L\0o\0n\0g\0i\0t\0u\0\x64\0\x65\0\0\0\x6\0@ \xd1\xc4\x8e\x82\xc7\xc5\0\0\0\x18\0h\0o\0m\0\x65\0L\0\x61\0t\0i\0t\0u\0\x64\0\x65\0\0\0\x6\0@H\x7f\x86\x11\xc2\x81\x35)

Not exactly human readable, but I'm afraid the nicer looking versions (e.g. qDebug()'s output) cannot be deserialized easily. Ideas?

Hello Dennis! Now that trunk is open for commits, if you could update the patch it would be great. Thanks.

@Torsten: I don't think QByteArray is the way to go. What do you think about passing a QSettings instance and a QString group_name_prefix like this:

ReadSettings(QSettings *settings, const QString &group_name_prefix="");
WriteSettings(QSettings *settings, const QString &group_name_prefix="");

The Qt Version of Marble would use it like this:

QSettings settings("kde.org", "Marble Desktop Globe");
ReadSettings(&settings);

and likewise

QSettings settings("kde.org", "Marble Desktop Globe");
WriteSettings(&settings);

Other applications could do

QSettings settings("example.com", "...");
ReadSettings(&settings, "Marble_");
...
WriteSettings(&settings, "Marble_");

Probably naming the methods SaveState/RestoreState.

What do you think?

Created attachment 35704 [details]
marblewidget-settings.diff

Just had a look at the current code and found similar methods to save/restore plugins' state. Here's a patch using a similar approach to save/restore the MarbleWidget state. The groupNamePrefix is not strictly needed, but might be nice to avoid name clashes.
In the patch I also made the home() method in MarbleWidget and MarbleMap const, is that a problem regarding binary compatibility?

Looks nice so far, but I have a question: Why don't we save all properties of MarbleWidget with this function (including these managed by QtMarbleConfigDialog and including the home location)? I'm not sure how hard it will be to realize and I'm also not sure if this patch does what you want or what the user of the API expects.

You should also make sure to keep the documentation up to date.