Hey all. I just wanted to take a quick moment to tell/remind you all that our (KDE) sysadmins rock! They have been very busy recently getting the move to git going. git.kde.org is running cgit, projects.kde.org is running Redmine, there's a web app setup to collect our ssh public keys for those of us who were using https. I spoke a bit with Eike Hein on irc today and he said "I don't think we've had an idle day this month really :-)" Sounds like the next step is setting up reviewboard. Amarok and Konversation are both migrated from gitorious.org to git.kde.org and will be used to test and setup the rest of the infrastructure we will want and need to do what we do best.
So fellow kde folk, please take a moment to thank these diligent guys and let them know how much you appreciate all they have done and continue to do for us all.
Tuesday, June 22, 2010
Monday, May 31, 2010
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.
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.
Monday, May 24, 2010
Multimedia/Edu Sprint day -1
I can't remember which day it is today besides that it's Monday. Tomorrow morning very early I'll hop on a train with Percy from Peru and George and go to Zurich, then fly home in our different directions from there. I believe a lot was done in this sprint. I have a longer todo list than I did before, that's for sure. I'll also be blogging more hopefully about the things I do going forward.
One thing I did last week but didn't blog about was to move the workspace tab from the application style area of system-settings down into desktop style area instead. I as many others I've heard were confused when we opened the desktop theme details settings and couldn't set the global plasma theme from in there. I combined that one with the existing workspace tab of the other kcm and call the combination desktop style. I hope this will be more usable and
discoverable.
One thing I did last week but didn't blog about was to move the workspace tab from the application style area of system-settings down into desktop style area instead. I as many others I've heard were confused when we opened the desktop theme details settings and couldn't set the global plasma theme from in there. I combined that one with the existing workspace tab of the other kcm and call the combination desktop style. I hope this will be more usable and
discoverable.
Thursday, May 20, 2010
Multimedia sprint
Today lots of people arrived for the first day of the Multimedia/Edu sprint including myself. 2 hours drive to Las Vegas, 4 hour flight to DC, 7.5 hour flight to Zurich, then another 3 on the train. I would have slept on the plane, but there were crying babies (and I was excited to get here). Mario is a great host and has all our needs taken care of, it's great to be here. I've met a few developers I've only known on irc so far, so it's been good though I am tired.
On one flight I did make a todo list of stuff I'd like to get done while here so will start to work away at that now. The plan so far is tomorrow to get all together and decide what we each want to do (and do the same each morning I believe). Anyway, enough for now, just wanted to get my 2 cents in about the day 1 :)
Wednesday, May 19, 2010
Headed to Randa, Switzerland
Hey all. It's been a while. Lots of good things are happening in KDE land these days. I wish I were helping with more of them but will be this week anyway. I'm waiting for a flight to Zurich right now then will hop a train to Randa where the Multimedia/Edu sprint will take place. Thanks to my sponsor and employer Collabora Ltd.
What do I hope to achieve while there? I will definitely be helping with whatever needs help in Edu land. I will also be presenting and discussing any possible tie ins between Edu and accessibility. Plane boarding soon will report more soon.
What do I hope to achieve while there? I will definitely be helping with whatever needs help in Edu land. I will also be presenting and discussing any possible tie ins between Edu and accessibility. Plane boarding soon will report more soon.
Monday, February 8, 2010
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).
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).
Wednesday, February 3, 2010
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 =)
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 =)
Saturday, January 23, 2010
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
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...)
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/([^/])/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...)
action recurse
end match
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...)
Subscribe to:
Posts (Atom)