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 api.kde.org docs.kde.org and englishbreakfastnetwork.org

The KDE gardening team has chosen as it's next target for gardening the documentation/api websites. https://community.kde.org/Gardening/docwebsites 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: http://download.kde.org/stable/krecipes/2.1.0/src/krecipes-2.1.0.tar.xz.mirrorlist

Enjoy.

Saturday, February 28, 2015

node.js experience wanted

Hello all,

If there's anyone in the community, or even just reading this blog, that has experience with node.js and a bit of time I would like to recruit you for a special task. The task is to get bodega-server (and maybe the webapp or admin client too if you're so inclined) to actually work again. It worked at some point in the past year from what I hear, but currently it just spews 404 error pages for any api call it gets. I gather that this is because the nodes that it uses have changed their api since it was written. My time is limited and I've poked it enough to not give warnings at runtime anymore, but someone that really knows the ins and outs of node.js could probably fix it much faster than I so I am asking for such a brave soul to come forward and get the next generation software/data/"stuff" distribution system to do so. I know you're out there and you're considering, stop considering, hop on #kde-devel or #kde-www or anywhere on freenode and find me or others trying to get this going. Or just look at the code itself here and throw me some pointers.

I can't promise much except fame, thanks, admiration of your peers, etc. but hopefully that's enough.

P.S. this couldn't happen soon enough, ocs/attica, knewstuff, and opendesktop/kde-look, etc. are really showing their age. Having bodega working would make a lot of awesome things possible again.

Friday, February 13, 2015

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

Wednesday, December 17, 2014

kdesrc-build is a very useful tool, here's why

I've been thinking for some time about writing a post about my favorite tool for building, rebuilding, testing, fixing random parts of kde software and how I use it (many times a day, depending on the situation).

For anyone that doesn't know, kdesrc-build is a script, written in perl, it lives in extragear/utils/kdesrc-build in the kde project heirarchy and can be cloned from kde:kdesrc-build if you've got your ~/.gitconfig as follows (if you don't you should add it, go add it now, I'll wait):


[url "git://anongit.kde.org/"]
       insteadOf = kde:
[url "git@git.kde.org:"]
       pushInsteadOf = kde:
kdesrc-build is very useful in that running it with no arguments it will build all of your kde stack. This includes all the frameworks (including Qt if you want it to), all library dependencies that come from git.kde.org and all applications. To start using it, just clone it, build it (mkdir build, cd build, cmake ../, make, make install, or sudo make install if you aren't the owner of /usr/local yet) and you can run kdesrc-build from any path your terminal happens to be in. The one thing needed is a .kdesrc-buildrc file to tell it what you want to build, where you want it installed to, which build options etc. you want. This is pretty straightforward though and most of the kde stack is in include files you can add from your .kdesrc-buildrc itself. Mine looks like this:

# Adjust all these settings at will

global


 qtdir /usr
 # qtdir /home/jeremy/devel/kde/src/qt5bulid/qtbase
 source-dir /home/jeremy/devel/kde/src
 build-dir /home/jeremy/devel/kde/build
 kdedir /usr/local

 git-repository-base kde-projects kde:

 cxxflags -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=return-type -Wno-variadic-macros -Wlogical-op
 # WARNING: opensuse users need -DLIB_SUFFIX=64 here, as long as FindKDE4Internal.cmake is used
 #          if you're using a distro without "lib64", remove the option.
 # cmake-options -DKDE4_BUILD_TESTS=TRUE -DLIB_SUFFIX=64
 cmake-options -DBUILD_TESTING=TRUE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_LIBDIR=lib

 make-options -j8
 #install-session-driver true
 branch-group kf5-qt5

end global

include devel/kde/src/extragear/utils/kdesrc-build/kf5-qt5-build-include

I go back and forth sometimes between distro packaged qt (in /usr) and my own built qt from git (in the other path) so I uncomment the one I want to use in those first few lines.

It's pretty simple and short, set 9 variables, include the kf5-qt5-build-include file and we're good to go. So for me, kdesrc-build with no arguments builds and installs many different kde applications, with their sources nicely organized under ~/devel/kde/src and their build folders easy to delete if needed in ~/devel/kde/build and installs into /usr/local where I have my XDG_* variables set to find applications, libraries, data, default configurations, etc. Also if some part of the workspace becomes deprecated and I need to remove old libraries, .desktop files, and such I can safely (from a terminal, not within X) nuke /usr/local/* and rerun kdesrc-build to rebuild everything that's current.

kdesrc-build frameworks - builds all the parts of kf5 itself.
kdesrc-build kdeedu - builds all the libraries and applications that have been ported to qt5/kf5 from kdeedu.
kdesrc-build --no-src kanagram - builds kanagram with my local changes for testing before committing the next feature, also useful to test patches from reviewboard (download, patch, kdesrc-build --no-src foo to build/install, run to test).
kdesrc-build --no-src khangman - builds whatever I've got checked out in kde/kdeedu/khangman at the time (currently an almost complete gsoc student's qml ui of khangman from his branch).
kdesrc-build --refresh-build - rebuilds everything with clean build folders using the cmake options from your .kdesrc-buildrc file, this is useful if you change these options and want to test them
kdesrc-build --refresh-build --no-src foo - rebuilds everything with a clean build and doesn't do any git updates, only tries to build what's on your local clone, this is useful when porting applications to kf5/qt5 to make sure cmake is reran when trying a build of local changes.

A good thing to know is that errors are all logged, and you can check them simply by checking source-dir/log/latest/foo/error.log (which symlinks to cmake.log, build.log, or install.log, depending where the error was).

One more nice thing, since kdesrc-build uses kde-project-metadata it can guess some projects from their location on projects.kde.org. So even if I don't have skrooge or some other extragear application in my .kdesrc-buildrc file or it's not in the included kf5-qt5-build-include file or whatnot, kdesrc-build skrooge will guess where skrooge comes from and clone it to the proper place in the heirarchy and build it.

In summary, kdesrc-build is useful for what it was created for, building the kde stack of software with your preferences.