GSettings vs QSettings

A few weeks ago after discussing with Luke Yelavich about what to work on in speech-dispatcher next I decided to take a stab at making it use GSettings for its settings. (You can see the work in progress here if you like.) I've used GSettings before for work projects so thought it would be a good/easy thing to take on.

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.

I'm here

It's been over a year since I posted anything. That's way too long. So what's going on in the projects I care about lately?
Speech-dispatcher will soon have a 0.8.5 release. There's a set of patches in the works on a branch on github that moves the audio to the server so we will be able to do useful things like label each pulse audio output with the client application name rather than a generic sd_espeak, sd_pico name for each output module. This way you'll see stuff like "Konsole speech", "Konversation speech" etc. volume controls for the speech volume control of the application's speech output. In order for this to work some other refactoring needs to be done in the espeak and other modules so stopping audio playback will be immediate etc.
QtSpeech has had some work done. The android and windows versions have been seeing some love lately. I'm optimistic that it can be included in an upcoming Qt release. Though I'm not sure why it hasn't been included yet.
KMouth has been waiting a QtSpeech release in order for it's kf5/qt5 branch to be merged to master.
KNewStuff could use some work. There was talk at a recent conference about adding the properties and such necessary for it to be used from QML. I'll follow up on that and see what has become of it.
All in all I feel like I haven't been around as much in the above projects as I'd like to have been. Life is busy and work is busy and such. I plan to spend a bit more time on these though. Even if it means I get slightly less sleep. Looking forward to a good rest of the year.