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

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

Renaming kttsd

Hey all, I thought I already blogged about this topic, but found I didn't. Anyway, one of the things I wanted to get done while in Randa was to rename KTTSD (Kde Text To Speech Daemon) to something with a meaning that is pronounceable. It's changed a lot since 4.0 (and 3.5, etc.) so a new name fits. A user suggested the name Kitty on a previous blog post, so I used that for about a day until another developer pointed out that Kitty exists (http://www.kesiev.com/kittyguide/home/) though it seems outdated/unmaintained. The next morning in Randa, we had a brainstorm session with other developers and came up with a few choices. We went with Jovie which happens to be a less commonly known and used name (and is also one of my daugther's name). So new in kde 4.5 Jovie will talk to everyone (if you or your distro setup speech-dispatcher correctly, etc. etc.)

Next step? Move the developer page from accessibility.kde.org about kttsd that's outdated to techbase and update it for D-Bus, 4.x documentation.

The state of free accessibility

Hello all. As some of you may have read at osswatch, or in Jeanie's open letter to Oracle, or even from mark doffman of codethink (or experienced yourself in some cases) the state of free accessibility technology is somewhat lacking as of late. I've spent some time investigating the various players, testing solutions, discovering what's out there, etc. and would like to give an account of how things are from my perspective as a KDE developer and as one who would like to see desktop accessibility on Linux and our other platforms flourish.

First maybe an introduction of the key pieces of this puzzle would help.

The first piece of the puzzle from a KDE developer's perspective is Qt's Accessibility classes here. As part of QtGui module most (maybe all) Qt widgets are accessible as far as they can be. They all provide description, state, role, and actions in Qt's way that allows them to be "seen" via accessibility on Windows, should allow them to be "seen" on linux/unix via at-spi2 (will discuss this piece a bit later) and allows them to be "seen" with carbon builds on Mac also (accessibility for cocoa is a feature request that has not been scheduled at the moment). So as far as gui developers are concerned, as long as existing Qt gui widgets (or derivatives) are used, we should be in good shape. Unfortunately, the next piece falls a bit short.

The next piece of the puzzle is the qt-atspi2 bridge. This is in the works and can be found here. This takes the form of a qt plugin backend for qaccessible. It bridges the gap between qaccessible classes and at-spi2 dbus interface. Though Mark Doffman at codethink has done amazing work here. The latest version is not quite ready to work with at-spi2 because of recent changes in at-spi2 itself.

The final piece of the puzzle for kde/Qt apps is at-spi2 itself. This has been developed quite a bit by various members of the gnome-accessibility community. I know Mark Doffman spent some time optimizing some things and fixing issues in there. Gnome is going to be switching from corba to this new dbus-based at-spi2 for gnome 3.0 (and possibly sooner, depending), so desktop accessibility will at last be unified on linux platforms. Unfortunately for Qt apps, the api recently changed quite a bit in january of this year, so the qt-atspi2 bridge needs to be updated to work with these changes. I have a description from Mark of what needs doing, but need to wrap my head around it before being able to help with the effort here, come join irc.gnome.org #a11y if you'd like to lend a hand. This really probably needs to become a community effort in the long run.

As can be seen above there is lots to do to make kde accessible, lots to do to make linux desktop accessible and lots to do to make sure everything is in place for everything to work nicely. So... come join the effort! join #kde-accessibility (I was often alone in there until recently Luke Yelavich of speech-dispatcher fame joined). join irc.gnome.org #a11y. get on some mailinglists, come to akademy (I hope to have a talk there, we'll see).

Kttsd 0.5.0

Ktts is finally getting a version bump since 4.0. What can you expect in this release (that will come out with KDE SC 4.4 as part of kde-accessibility)? Well, a lot of things have changed, but more is still a work in progress. The most significant change is that ktts now talks directly to speech-dispatcher, which is a daemon that handles all speech from kde, gnome, console, etc. Speech-dispatcher itself supports many synthesizers like espeak, festival and so on. The plan was to make ktts expose all of the capabilities of speech-dispatcher, but it didn't quite get to that point yet.

The first new thing you should note is that if speech-dispatcher is set up, ktts doesn't need any voices configured at all. speech-dispatcher uses whichever synthesizer it can find and plays a dummy wav file if it can't find any. (The talkers tab in kttsmgr doesn't really affect anything inside speech-dispatcher yet anyway...) You can play with the different voices from the jobs tab though, setting different pitch, volume and speed, hitting apply, then clicking speak clipboard contents (I'll add a test button for 4.5, or possibly 4.4.1 if the translators let me).

One thing that didn't make it in to this release was the gui for setting up speech-dispatcher. It has a command-line configuration tool called spd-conf which works fine. But I would like to get a gui for it in the next release if time permits.

I'd also like to join kttsd and kttsmgr into one process/app, kttsd doesn't do job management anymore because speech-dispatcher does all that now (yes I know the jobs tab will be renamed at some point, since it doesn't deal with jobs at all). So joining kttsmgr and kttsd makes sense I believe. Alternatively making speech-dispatcher have its own dbus access would remove the need for kttsd completely, kttsmgr could then just be a gui for configuring and controlling speech-dispatcher itself. We'll see which direction things go as this progresses.

Anyway, junt wanted to give a short update. Enjoy the wonder that KDE SC 4.4 will bring =)

svn2git rules!

In case anyone has been hiding under a rock lately, yes kde is moving to git in the foreseeable future. There is a meeting weekly in #kde-git about the migration progress, what needs doing still, and what is done. One task that had not been taken on very much is writing the rules to import from svn into git (using svn2git, which is a handy app thiago wrote a while ago).

As one of the few people working on kde-accessibility these days, I took it upon myself to check those rules. This was a bit harder than I imagined it would be, and harder than it should be due to lack of documentation (or possibly my lack of reading the existing documentation?) and some nuances of the rule syntax and kde's svn history itself. Just thismorning I finished this and want to share some things I learned here for others doing the same for other modules.

#1 match lines should end with a / in most cases.
if you are matching a path in svn, you have to remember to add the trailing / or you will get cryptic svn errors about being unable to get data of a non-object or somesuch. Thanks to argonel for pointing this out to me the other day.

#2 action recurse rules are tricky but necessary.
I first copied konversation's rules to start kdeaccessibility's ruleset, then merged in kdeaccessibility parts of kde-rules-main. There was a problem though, svn2git would get stuck when it got to creating the 4.0.0 tag, because the 4.0 branch didn't exist. Then I noticed a rule I had missed from kde-rules-main

match /(branches|tags)/KDE/([^/])/
action recurse
end match

after adding that though, the import would fail even earlier than before, because the above match would match files as well as folders, so entries with /branches/KDE/4.0/README which cannot recurse (because it's not a folder...)
The answer was to make the recurse match only what it needed to, so to create the 4.0 branch I set it to match /branches/KDE/4.0/ with a min-revision and max-revision of when /branches/KDE/4.0/ was created.

Problem with that match is that it didn't match 4.1 or others, since the match is a regex this was easy to fix, just make the match terminate with $ so it only matched svn revisions that are folders 4.0, 4.1, etc. etc.

I'll start looking into another module's rules next, so we can get this migration to git done. Any opinion which module I should look into next (kdeaccessibility was a good choice as its apps never spent time in kdereview or playground...)

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

KNewStuff bug fixed (finally), and accessibility

Talked to aseigo on irc this morning and was asked to fix a bug with kns. Previously there were two methods in the KNS::Engine class, downloadDialogModal() and downloadDialog(), the latter's documentation saying it's asynchronous and uses signals to tell the app of activity in the non-modal dialog. Since plasma's dialogs are all non-modal so it can update, etc. it needs kns to show a non-modal dialog for it's purposes. Easy fix, right? just send a signal saying what entries were changed when the dialog closes. Problem is KNS::Engine isn't a QObject (I can't remember why, but will remedy that with the next BIC fix), so a bit of tom-foolery was needed. I added a new downloadDialog(QObject * reciever, const char * slot); method that will connect the private object's signal to your slot for you. It's ugly, but it works for now. So now apps can actually use the non-modal version of the method to get new stuff, yay!

On another note I've been investigating the state of kde-accessibility lately, and have learned a lot with the help of some folks from gnome-accessibility, and other places. It seems we are a bit behind the curve, but can probably catch up easily. A couple things are on our list:
1. kttsd has a redesign that phantomsdad designed before he left that should simplify things a great deal by using speech-dispatcher rather than plugins for each synthesizer. This also has the effect that speech-dispatcher will be doing all the synthesizing, and all the output to the speakers as well, and may make kttsmgr a gui component to control parts of speechd (or at least speechd as kttsd interacts with it).
2. some gnome? devs are working on a bridge between AT-SPI and dbus, once this is done, existing Qt accessibility functionality should be usable right after Qt's x11 implementation is using the dbus from that bridge (I'm a bit unclear on this, but it sounds like it will work).
3. At this point I believe the only step to make Qt/KDE apps usable with the orca screen reader will be to turn on accessibility in qt QT-ACCESSIBILITY=1, and add accessible names and descriptions to widgets in our apps (and maybe in our kde libraries also? i.e. default name/description for kpushbutton)

I believe these steps will go a great deal towards making kde a more accessible desktop solution. (which incidentally makes us an option for government workers, etc. who are required to have accessible software from what I gather).

devs.clone();

I've been testing more and more features of kde4 lately, and have noticed some things I'd like to fix if I had the time... I'm betting others have some of these also. I'd really like to fix up kttsd and get it working well again, as that is one of the things I miss from kde3 (listening to irc, etc.) It is somewhat working now, but could definitely use some love. Seems the maintainer ported it while kdelibs was in fluctuation, but there are still some things that look like they were written with Qt 3. Other kdeaccessibility apps could use some ui love also, simple things like finding out why &Language: can't be a buddy of a KLanguageButton in the kmouth setup window, etc.

I almost wonder if other devs have these side projects in their mind they'd like to work on also, if we should start pointing people to a page with junior jobs, or side projects we could help a newcomer figure out and maintain. There's a mentoring site here: http://www.kde.org/getinvolved/development/ that we could use, or something on techbase could be made possibly.

Anyway, I think we are doing great work, but we could use a few clones ;-)