Thursday, September 22, 2016

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.

Tuesday, August 9, 2016

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.

Thursday, June 11, 2015

Speech Dispatcher 0.8.3 is out

Speech Dispatcher 0.8.3 is out now. I'll shamelessly post the release announcement e-mail below, but with this you can build and use QtSpeech for linux from the dev branch of qtspeech. It contains all the api QtSpeech requires for it's speech capabilities (QtSpeech is an optional dependency of knotifyconfig, knotifications, kanagram, khangman, and okular (frameworks version) as well as the replacement for Jovie.

Speech Dispatcher 0.8.3

Announcing the availability of Speech Dispatcher 0.8.3 developed as a part of
the Free(b)Soft project.

* What is new in 0.8.3?

 - Add API methods to get language, rate, pitch, and volume.

 -  A lot of code cleanup, and compatibility improvements.

 - Removed all references to GNOME Speech, since it has long since been

 - Fix some inconsistancy in the SSIP API for voice type.

 - The SET VOICE SSIP command is now deprecated, and will be removed in 0.9.

 - The C library API now provides macro definitions for major, minor, and micro
   versions in libspeechd_versions.h.

 - The libsndfile library is now a mandetory dependency to improve the user
   experience around sound icons.

 - Fix a possible crash in the festival driver.

 - Add a configuration option to the espeak driver to show voice variants in
   the voice list. This will remain until a proper variants retrieval API is
   added for compatible synthesizers.

* Where to get it?

  You can get the distribution tarball of the released version from

  We recommend the use of sound icons with Speech Dispatcher.
  They are available at

  Corresponding distribution packages should soon be available at
  your distribution mirrors.

  The home page of the project is

* What is Speech Dispatcher?

  Speech Dispatcher is a device independent layer for speech
  synthesis, developed with the goal of making the usage of speech
  synthesis easier for application programmers. It takes care of most
  of the tasks necessary to solve in speech enabled applications. What
  is a very high level GUI library to graphics, Speech Dispatcher is
  to speech synthesis.

  Key Speech Dispatcher features are:

  - Message priority model that allows multiple simultaneous
    connections to Speech Dispatcher from one or more clients
    and tries to provide the user with the most important messages.

  - Different output modules that talk to different synthesizers so
    that the programmer doesn't need to care which particular
    synthesizer is being used. Currently Festival, Flite, Epos, Espeak
    and (non-free) Dectalk software, IBM TTS, Pico and others are
    supported. Festival is an advanced Free Software synthesizer
    supporting various languages. Espeak is a very fast multi-lingual
    Free Software synthesizer.

  - Simple interface for programs written in C, C++ provided through a
    shared library. Python, Common Lisp and Guile interfaces. An Elisp
    and Java libraries are developed as sperate projects speechd-el
    and speechd-java. Possibly an interface to any other language can
    be developed.

* How to report bugs?

  Please report bugs at .
  For other contact please use either the above link or our mailing list
  <> .

Happy synthesizing!

Tuesday, May 5, 2015

KMouth is alive and well

I meant to have a post about Gardening efforts next, but KMouth is improving lately, so I'll throw out a quick post about progress.

KMouth master branch is now Qt3 free. It's still using K3Process for the speech synthesizer command-line calls, but all Qt3Support is gone.

In other news I started a quick Qt5/kf5/QtSpeech port of it on the frameworks branch. It runs, it speaks (with a bug fix in gerrit for QtSpeech).

It looks like this currently:

There's definitely room for improvement, but it's a good start I think. Note this wont be hitting master until after QtSpeech gets a release and KDE Applications depend on it (probably Qt 5.6).

Thursday, April 23, 2015

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.

Tuesday, March 31, 2015

Next KDE Gardening project and

The KDE gardening team has chosen as it's next target for gardening the documentation/api websites. The initial objectives are there on the wiki, but feel free to modify/update them if I got anything wrong or something is already in the works. The general idea is to improve these sites by getting kf5 based applications and libraries (which aren't frameworks themselves) apidocs, documentation, and code checks on these sites as they were in Qt4/KDELibs times. 

Another good objective is to make them work faster/better by not recreating everything each day, but only incrementally updating their content somehow if possible. 

And finally I'd like to get bug products/components for each of them so if issues are found we, as a community, can track the issues and fix them as a team.

The plan is to focus on these over the course of April and May and at the end of May have a gardening day on a saturday to wrap it up like we did on the KRecipes gardening day.

P.S. we'll be using #kde-devel for discussion of this project and how to help contribute, come join us and let's get some stuff working better in this area.

Monday, March 23, 2015

KRecipes 2.1

The KDE Gardening team has at last finished the Love project KRecipes with the 2.1 release which can be found here: