There are many advantages of using GSettings over plain ini-style files.
- Type checking (You can't enter a string for a numeric setting for example).
- Notification of setting changes.
- Command-line changing of settings.
- Default values for settings defined in the schema(s).
On that wip branch speech-dispatcher itself has been changed to use GSettings and also reacts to many setting changes dynamically. It doesn't react to changing the port type or port number or unix socket path dynamically, since we have no mechanism to tell client applications that it is changing. There are also GSettings schemas for the output modules, just need to make them read their settings from GSettings instead of the old ini-style .conf files. spd-conf also has been modified to write to GSettings rather than .conf files. That change alone reduced the spd-conf python script by quite a few lines of code and made it a lot easier to read.
As I was doing this work I got thinking about the differences between GSettings and QSettings. Besides one being glib/c based and the other being Qt/C++ they are really pretty similar. There are a few differences though:
- QSettings doesn't emit signals when a setting changes. (I found a few forum posts asking why this is with possible workarounds. Nothing built into QSettings though).
- QSettings doesn't have a schema for the settings themselves. There's no way to introspect a setting file to see what settings are possible. It just depends what keys the application reads.
- QSettings doesn't have a command-line tool to set the settings. Since QSettings is cross platform it uses the Registry by default on Windows, PList files by default on macOS, and ini-style files on linux
- QSettings does have type checking, but no range checking or anything like that.
I was a bit disappointed that QSettings that I've used for many many years is lacking these seemingly obvious and probably useful features. I wonder if we as a community implemented these features in QSettings if the Qt company would accept them.