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.

Dusting KMouth

Besides gardening lately (more on that next time) lately I've been looking into what needs and used to use KSpeech/KTTS/Jovie. As QtSpeech will replace the functionality Jovie provided I thought I'd look at what needs doing to get stuff using QtSpeech.

Okular's frameworks branch (or maybe it's been merged to master by now, not sure) is optionally using QtSpeech.

KNotifyConfig and KNotification are optionally using QtSpeech as of the last frameworks release already.

KHangMan and KAnagram have been using QtSpeech optionally since December of last year or so.

This leaves the big one, KMouth. Unfortunately KMouth has been bitrotting since about 2006 or so. All commits since have been minor or bug fixes. Many because KFoo classes changed and were used in KMouth. It's master branch still uses Qt3Support and K3ListItem, etc.

I started a couple of months ago to start porting it away from Qt3Support and K3* so it can be ported to Qt5 and QtSpeech, but it's been a long slow process. Current progress can be seen on the noqt3support branch, but even the last commit there is from a couple of months ago. Part of the trouble has been getting the PhraseBookDialog with it's accompanying model and treeview to work as it used to including drag and drop, copy/paste, import, export, save/load, etc.. Many bug fixes are also in the works, and I am positive it will be better than before once it's done, but it's taking time since I don't want to break loading phrasebook files of any existing users (If there are any out there, please shout, I'd love to hear from you about how you use KMouth).

Once KMouth is ported to QtSpeech I believe most/all users of the old KSpeech dbus api will be safely using the new QtSpeech library.

P.S. Once it's ported to Qt5/KF5 and QtSpeech KMouth could use some updating. A couple of years ago I saw a fancy speech application on the evening news that enabled a young man to speak with his family by tapping icons on an ipad which then spoke for him. KMouth could be useful in the same way with a bit of polish in my opinion.

The Future of Kttsd

As you may or may not know, Kttsd is in the middle of some changes. Before Gary Cramblitt (aka phantomsdad) left the project, he made (and documented very well) a design to make kttsd basically just wrap speech-dispatcher. This design has many advantages, it simplifies kttsd code quite a bit, adds new functuonality, and makes kttsd better able to focus on what it does well, which I see as being the voice for KDE applications/desktop/platform. Kttsd has always been very good at filtering things like notifications (I use it to listen to irc and have for ages), and at providing an interface to an otherwise obscure sub-system (speech). However I also think there is definitely room for improvement =) And here's where you come in dear blog reader.

I'm considering changing up the ui a bit, to try to bring it into this century. The job list/control tab is somewhat dated, and it has always seemed a bit cumbersome to me. I'm considering making the job list more of a log of what has come in from what apps, with an easy to see view of what the filters did to the text for easy tweaking of filters (I seem to spend a bit of time each week trying to tweak the filters in one way or another). Other requests that have come on bugs.kde.org have been the ability to dynamically switch the current voice being used. So I'm thinking what if we make the jobs tab be more of a log and add a new tab for real-time speech control (change the current voice to male/female, language, pitch, speed, etc. all in realtime. Opinions anyone?

If we do the above we could also easily have a menu in kttsmgr's system tray icon to choose the voice, adjust speed/pitch, etc. on the fly also. So from you I'd like some feedback about which features you currently use in kttsd (talker chooser filter?, string replacer filter? easy (or not) access to festival/espeak/other speech system?) and what you'd like to see kttsd allow you to do in the future.

Thanks for reading and I hope next time to have some pretty pictures of a nice interface =)

KTTSD using speech-dispatcher

Hey all, lately I've been working a bit on porting kttsd to use speech-dispatcher as per Gary Cramblitt (previous kttsd maintainer)'s design from back in 2005. Anyway, I thought I'd give a bit of a progress report on the effort here.

First a quick summary of Gary's design though. The idea is that speech-dispatcher will do most of the work previously done by kttsd (job management, synthesizer communication, etc.) which is simplifying kttsd's codebase quite a bit. The reason to switch to using speech-dispatcher is that it's a system app, so console apps can use it to synthesize text, kde apps (directly or via kttsd) can use it also, and it will do all job management, so apps wont be trying to talk at the same time, etc. Also gnome is switching to use speech-dispatcher exclusively for 3.0 release.

So status, I've got two machines both running speech-dispatcher 0.6.7 (configured with festival and espeak) and kttsd notifications are going there directly and working fine. There's still some work to do to get the job manager in kttsd to show all jobs from speech-dispatcher, and figure out how to represent all the voices speech-dispatcher has configured in the kttsd talker tab, but it is functional. I've got all the plugins for synthesizers removed from my branch, and took out the sentence boundary detector plugin also, as all that is done by speech-dispatcher. I'll be working closely soon with speech-dispatcher itself, adding some missing functionality to fill in the gaps of what kttsd used to be able to do and speech-dispatcher currently can't do yet (basic stuff like which job is currently being spoken, repeating jobs, etc.).

I've also removed the output methods (alsa and phonon) from the branch, as speech-dispatcher sends the output to the speakers itself. This avoids a bug we've had since 4.0 where when using phonon and the xine backend, speech got cut off quite often.

I hope to have kttsd using speech-dispatcher exclusively by 4.4 and have it provide a gui to set up speech-dispatcher also (besides prioritizing the available talkers that speech-dispatcher provides). My end goal is to have a setup where I can set apps like kopete and konversation to send new message notifications to kttsd, have it filter the notifications, and speak them. Obviously much more will be possible, but that's my itch anyway =)

P.S. if you want to try the branch, it's at https://svn.kde.org/home/kde/branches/work/kdeaccessibility-kttsd-using-speechd/kttsd