[QSettings] Why limiting to plain file or registry ?

[lauranger]

Hi
What about storing QSetings in something different from MS-Win registry or a plain file ?
As QSettings offer to register a format in the form of a read and a write function dealing with a QDevice, why restrain the kind of device to only a QFile.
What can be done to benefit from QSettings architecture (and .ini format handling) if one need to store configuration in something else, say a DB ?
Thanks in advance.
Laurent G.

[wysota]

But who says you're limited to .ini files and registry? That's what Qt uses, so that's what is implemented. Nobody forbids you from registering a different format. You can store data in a database using QIODevice too, so what is the problem?

[AlexKiriukha]

And as always you can easily subclass QSettings to suit your needs.

[gfunk]

A real DB may be overkill for just storing key-value pairs. And it begs the question, which DB? there's so many out there. The way it's been done is probably satisfactory for most common, light users, and follows familiar, standard conventions particular to each platform. And as always, it's extendable.

[lauranger]

But who says you're limited to .ini files and registry? That's what Qt uses, so that's what is implemented. Nobody forbids you from registering a different format. You can store data in a database using QIODevice too, so what is the problem?

Hi Wysota.
The problem is the QIODevice is instanciated by QSettings and there is no virtual method/ entry point for changing that without rebuilding nearly the all things.
I don't ask for Trolltech or anyone to implements the Db thing or so.
I'd just like that have the .ini (this formats because it exists) formated 'virtual stream' to be stored where I fancy to dump it to and get it back decoded from where I can fetch it.
I don't want to write another format, I'd just like to choose the underlying storage for it, and the registerFormat functions are no help in this case.
But thanks answering :)
Regards
Laurent G.

[wysota]

Hi Wysota.
The problem is the QIODevice is instanciated by QSettings and there is no virtual method/ entry point for changing that without rebuilding nearly the all things.

Who forbids you from creating and using an own stream in the read or write functions?

[lauranger]

Who forbids you from creating and using an own stream in the read or write functions?
Having to rewrite a format (I did not see where to get "back" the read and write functions for .ini formats, in the public interface of QSettings) may not forbid, but just not encourage to use such a solution.

[wysota]

Having to rewrite a format may not forbid, but just not encourage to use such a solution.

QSettings is intended for simple storage of configuration settings. Nobody says you have to use its interface. You can store your configs in an xml file with about the same amount of effort as using QSettings. It is just an interface for a dedicated solution.

[lauranger]

QSettings is intended for simple storage of configuration settings. Nobody says you have to use its interface. You can store your configs in an xml file with about the same amount of effort as using QSettings. It is just an interface for a dedicated solution.
Thank you for my freedom ;)
I used QSettings in a precedent project and I appreciated the easiness, the functionality, and
was wondering it could fit with another storage. It don't. OK. Sigh :crying: ;) Some more coding in perspective.