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.

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
   deprecated.

 - 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
  http://www.freebsoft.org/pub/projects/speechd/speech-dispatcher-0.8.3.tar.gz

  We recommend the use of sound icons with Speech Dispatcher.
  They are available at
  http://www.freebsoft.org/pub/projects/sound-icons/sound-icons-0.1.tar.gz

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

  The home page of the project is http://www.freebsoft.org/speechd

* 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 https://its.freebsoft.org/its/issues/project/1876 .
  For other contact please use either the above link or our mailing list
  <speechd@lists.freebsoft.org> .


Happy synthesizing!

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).

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.

QtSpeech progress

This week some changes in knotifications/knotifyconfig/kanagram/okular are in the works. The kanagram changes are already on master, the others are in review. Those changes are bringing back the use of text to speech features via the new QtSpeech module. Some have asked what the status of QtSpeech is, so I thought I'd share a bit about it here.

Frederik Gladhorn created the QtTextToSpeech module a while ago as a test to see how feasible it would be to wrap all the platforms Qt is supported on's TTS APIs in one easy to use Qt API. This turned out to be a great idea in my opinion. The predecessor to QtSpeech in KDE applications was Jovie, formerly known as kttsd. While it worked for the most part it required a daemon to be running which spoke with different synthesizers (originally) then was modified to use speech-dispatcher directly instead (when it was renamed to Jovie). QtSpeech on the other hand is a library. If you want to use it, you link to it in your application, create a QTextToSpeech object, and pass any text to speak to it's "say" method. No D-Bus connection required, no daemon required, just a small, light library that wraps the native platform TTS API directly.

As for the status of QtSpeech, I'm afraid it's not quite ready for prime time. It wont likely get added to Qt 5.5 which has feature freeze next Monday. It is however ready to be tested, improved, etc. on each platform. Most of it's API is implemented completely on linux, The basic API (saying text) is implemented on Android, Windows and Mac OS X. Patches are on gerrit to implement the rest of the API (getting available voices, locales, setting the voice) on OS X and will be written soon for Windows also. I plan to spend a bit of time on it each week so it will be ready for release with Qt 5.6 and I hope anyone else interested will join us.

More information about QtSpeech can be found here http://qt-project.org/wiki/QtSpeech. I hope this update has been helpful.

P.S. Here's a work in progress screenshot of the example widget Frederik created which is inside the QtSpeech git repository as it appears on OS X.

Edit: The wiki has been moved apparently. It's now found here: https://wiki.qt.io/index.php?title=QtSpeech

Accessibility is alive (QtSpeech progress, Jovie's deprecation)

For some time I've been considering what to do about Jovie which was previously known as ktts (KDE Text To Speech). Since before the first KDE Frameworks release actually, since kdelibs used to host a dbus interface definition for the KSpeech dbus interface that ktts and then Jovie implemented. I have a qt5 frameworks branch of Jovie, but it didn't make much sense to port it, since a lot of it is or could become part of the upcoming QtSpeech module. So Jovie has no official qt5 port and wont be getting one either.

What will Okular, KNotify, and other applications that want to speak to users do instead? The answer is QtSpeech. QtSpeech is a project started by Frederik Gladhorn to bring speech api's to all the platforms that Qt supports. It is still in its infancy, but is quickly improving. A few weeks ago when I built my kf5 stack with kdesrc-build I noticed that kdepim(libs?) was depending on it and it hasn't been released yet, so I got motivated to send some improvements to qt-project. Frederik and Laurent Montel have been pushing fixes and improving it also. It is as easy if not easier to use than the KSpeech dbus api (and doesn't require dbus either) and can be used to speak text on linux/unix, osx, windows, and android platforms so far. If you are an expert on any of these platforms please send patches to implement api on these platforms in their backends, the more eyes on this project the faster we can get it solidified and released.

You may be asking but what about feature X in Jovie that I will miss desperately. Yes there are a few things that QtSpeech will not do that Jovie did. These will either need to be done in individual applications or we can create a small framework to add these features (or possibly add them to QtSpeech itself if they make sense there). The features I'm thinking of are:

1. Filtering - Changing ": Hey QtSpeech is really coming along now" to "jpwhiting says 'Hey QtSpeech is really coming along now'" for KNotifications and the like. This could likely be implemented easily in knotify itself and exposed in the notifications configuration dialog.
2. Voice switching - Changing which voice to use based on the text, or the application it is coming from or anything else. This might make sense in QtSpeech itself, but time will tell if it's a wanted/needed feature.
3. User configuration - Jovie had a decent (not ideal, but it was functional) ui to set some voice preferences, such as which voice you wanted to use, which pitch, volume, speed, gender, etc. This will become the only part of Jovie that will get ported, which is a KDE Control Module for speech-dispatcher settings. This may also change over time, as speech-dispatcher itself possibly grows a ui for it's settings.

All in all, progress is being made. I expect QtSpeech to be ready for release with Qt 5.5, but we'll see what happens.

Minor tasks

Just a quick note to let you all know what I've been up to this week. Monday I took a look at what will be needed to finally fix Jovie (make it use the voices you add, etc.) The rest of the week I've spent some time setting up a local copy of accessibility.kde.org to play with. Last night I got it working with chihuahua layout which looks nice, but has some accessibility issues. I let the awesome crew in #kde-www know about them and a fix is in the works. I wont switch the site over to the new layout until it's accessible, don't worry. I would like to clean up the content on there though, it's very outdated, and much of it could probably move to techbase and/or community.kde.org.

Oh, I've also signed up to be a SoC mentor. This summer is going to be awesome.

It's alive!

I'm very excited to announce that qt-atspi has seen some major progress lately. Frederik Gladhorn has been kicking some major butt and has gotten it into much better shape than it has been previously. I just tested his "experimental" branch, and I've got to say wow. Since I started testing and playing with qt-atspi my holy grail has been to try to get our qt calculator to work with orca as well as gcalctool does. Today I need to get a new holy grail. Fired up orca, fired up the calculator test app and was delighted to hear every button, every change, selection, activation all spoken to my ears through the chain from QAccessible to qt-atspi to at-spi2 to orca to speech-dispatcher to espeak (Quite the chain, I know). In the next days and weeks we'll likely get qt-atspi packaged for distros to test and I'll definitely put some polish on the how to build it yourself tutorial I put on techbase last year for those that want to play with it sooner :)

Frederik you rock!

P.S. Sorry for no pretty pictures, maybe for my next post I'll learn how to make a videocast of qt-atspi in action :p