it’s been a looong time since I wrote in this blog, lately things usually end up in the Qt blog. I hope everyone is reading up on accessibility and other fun things Qt there My contributions to KDE were code-wise mostly small things (such as helping a little with porting Kate’s accessibility implementation to Qt 5) and I’m happy that Parley found new maintainers (thanks Amarvir and Inge!).
I’ve been wondering for quite some time though how the state of Plasma Next is when it comes to accessibility. In this case accessibility is mostly how the applications and desktop shell expose semantics to the accessibility framework via an API (on Linux the beast is called AT-SPI, a DBus API). The goal is that assistive technology such as a screen readers (Orca), the screen magnifier, or Simon can pick up what’s going on and assist the user. This allows for example blind people to use the software. The big thing here is that while Qt never had good support for QGraphicsView accessibility, we plowed away at making things work well with Qt Quick. This afternoon I finally got around to looking at the next iteration of the KDE desktop for real. In fact I’m writing this in a running Plasma Next session on top of the frameworks 5 libraries. It feels a bit like the porting from KDE 3 to 4, except that most things seem to just work so far.
I ended up running the neon5 packages on top of Kubuntu. I don’t manage to keep up with the speed of KF5 development and whenever I want to run anything I’d be building and the day is usually over when I figured out the dependencies and such. Instead I now ignored all warnings (big red signs saying: “don’t do this at home kids”) and installed the daily build packages (for some reason the weekly one didn’t work at all on my laptop). After that I built and installed the things I was interested in over the system packages to be able to debug them. This is a horrible way of messing up one’s installation, but since the neon packages install nicely into /opt, I decided to go for it. I ended up wanting to debug a few things, so now I have my own build of qtbase+declarative+plasma-frameworks+plasma-workspace+plasma-desktop.
The first issue I ran into is that Gnome changed their interpretation of a settings value which is reflected on DBus in the a11y service… the property IsScreenReaderEnabled will now return false, even when a screen reader is running. I’ll have to find a better way of starting Qt’s accessibility on Linux, hopefully for Qt 5.4. There is no real standard to these things since so far it was a Gnome-only thing.
For now the work-around is to simply run this one-liner before trying anything else:
gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true
With that in place I could restart plasmashell and see that … there was not much to see.
Before running a screen reader, it makes sense in this case to use one of the explore and debugging tools first to see what is exposed about the desktop.
I ran “Randamizer” which is an example that comes with libkdeaccessibilityclient, the alternative is “Accerciser”. Both tools now showed me plasmashell (yay!) and I could navigate to see the hierarchy of accessible elements. Which turns out to be completely empty (meh). I was not quite sure if this was due to bugs or simply really no information was provided, luckily (that’s easier to fix) it turned out to be the second one.
I started writing a few patches for the above mentioned plasma repositories and now I have at least a few things showing up, I can see the clock is there and even see the time displayed. I can also see the desktop element as such and some panels. The patches need cleaning up, but I’m happy that getting the basics to work will be relatively easy.
Now I don’t think I’ll manage to go though all of KDE and Plasma to fix simple issues, even though I’ll try to get the basics covered in the next few days. Consider this is a call for help, please join KDE’s accessibility mailing list (IRC is also good) and help out.
The most basic work is to look at the Qt Quick items used in Plasma and add some simple information to them. For example for the Button.qml in plasma-frameworks the patch will add these lines:
They are just a few bindings, but with QML it is impossible to automatically detect the meaning of a an item – is it just decorative or part of a control? Where is the actual control? Which Rectangle has which significance?
This is why it’s important for authors of Qt Quick UIs to use standard controls where possible. Qt Quick Controls shipped with Qt are accessible, the Plasma ones will soon be, I hope When writing custom controls, the properties as shown above need to be added.
For more information on what properties are available and should be set, check the documentation for the Accessible attached property.
I’ll be talking about accessibility for KDE on Sunday afternoon, please join me and help getting your application into the hands of ever more users.
At the same time I’ll be happy to talk about the Qt Project. And I’m looking forward to meeting so many old and new friends.
Quite often the question comes up how to build a KDE application.
Now we have great tools such as kdesrc-build and buildtool and long wiki pages on techbase…
But many of these aim at building not just one application but the world. Or at least kdelibs and everything on top of it. To start development, it’s often easier to build just the application you care about. Lately for a quick patch, that’s what I’ve been using. So if you’re not yet hacking on the internals but just want to build let’s say Parley, here you go:
I bet there is much to add and improve, so please help make techbase nicer for new contributors, we all started at some point, right I wonder if this approach should be more mentioned as the default way of building an application – it just takes a couple of minutes and you’re good to start hacking.
This post was triggered by some great Parley patches I received from Christian Muschick, who also happened to ask how to best build the application without messing up his system.
Hello planets, long time no see…
I don’t blog unless there’s something interesting to say, so here it comes: after less than a month I’m happy to release qt-at-spi 0.3 succeeding version 0.2.
What is that thing? A bridge that lets Qt applications interface with the AT-SPI accessibility framework that GNOME provides. For users that mostly means that the Orca screenreader should work nicely with Qt applications.
This project keeps evolving and as you’d expect in an accessibility plugin that is completely hidden from the user, development is just about bugfixing and getting it in shape to play nice with other existing infrastructure.
What made me happy this time around, and what triggered the short cycle since the last release is that I started getting more and more feedback from Orca users.
Thanks to Joanie and Mike and others I could finally nail down some old issues in the tree view handling.
As always this goes together with some fixes in Qt itself, so you might want to grab the 4.8 branch of Qt that will soon be 4.8.2 if you want to try the latest and greatest.
Changes since 0.2:
- Send keyboard events only when someone is listening
- Fix caching of tree and table items (Orca will no longer read outdated data)
- Fix at least one crash and one off-by-one error when reading tree items
- The usual internal cleanup and improvments that won’t be noticable
Dependencies: Qt 4.8.0 and newer.
You need a distribution that uses AT-SPI 2 (check your packages, any recent distro should do, this is part of standard GNOME).
The source can be found here: https://gitorious.org/qt-at-spi
It doesn’t give a file with file name extension, but extracting it should work fine.
For help setting things up, please refer to: http://userbase.kde.org/Accessibility
And for a bit more information for developers: http://techbase.kde.org/Development/Tutorials/Accessibility
Of course you find another crasher the day after the release, so grab v0.3.1 instead which fixes accessing some invalid objects and some more issues in for example KMail.
Download the tar.gz from gitorious: http://gitorious.org/qt-at-spi/qt-at-spi/archive-tarball/v0.3.1
We all know that KDE is a group of awesome people and friends. Now I had the special luck to have a friend who has friends that got him to smuggle a small present from the KDE e.V. to me (thanks Olivier). Yeah, just like that, because I happen to be a member of the KDE e.V.
The KDE e.V. is an organization that tries to help the KDE project in many ways. Non-technical ways that is. The e.V. (which means “eingetragener Verein”, German for “registered association”) helps in organizational matters. It enables the KDE community to meet by helping with travel costs for example. Or organizing Akademy, our yearly meeting. And it supports the numerous sprints where we meet simply to get stuff done.
You can support KDE in many ways. If you’ve been involved in any of our activities, well, don’t worry. You do enough probably – spending your spare time to improve KDE is the most valuable for all of us. Be it artwork, usability, helping others (in forums, on mailing list), improving documentation (for example userbase.kde.org) or maybe even writing code.
If you enjoy using KDE and want to give back without sacrificing as much time and energy, we offer you a new and convenient way: Join the Game – you can easily donate some money. And you even get a nice present as thank you. Yes, now you can become a supporting member of the organization that helps keeping the KDE community going!
In other good news: Qt 4.7.0 is released! Now you can start playing with Qt Quick (qml/declarative). I’m curious how you like it. I tried it and I like many things about Qt Quick, but sometimes it is noticeable that it’s fresh new code that needs some more poking at When will we have the first KDE application that uses Qt Quick? (OK, after Plasma, which already has some integration…)
Due to a small change in the createtarball script from kdesdk I messed up the tarball for attica 0.1.90, so without further ado, here’s the next attempt.
I hope this will be the final version 0.2.0. But then again I already said so the last time
Following the established “it’s not released until it’s been blogged about” paradigm, I’d like to announce a release candidate for Attica 0.2.0. I like the KDE versioning scheme, so this gets a nice 0.1.90, you see it’s not intended as final and stable, though I hope it is.
This release makes me happy, since we had lots of contributions from different sides. In many places it implements the yet to be finalized Open Collaboration Specifications 1.6 already. And this is to a large part because Mateu Batle worked a lot on it. Thanks! We also had Martin Sandsmark improve things for his GSoC project.
Finally we will have support for GPG signing “stuff”, so we can start to make use of the web of trust. This means we can provide better information when to be careful when getting “things of the internet” via KNewStuff. Of course this requires a lot of work still, from extending UIs such as KNewStuff to actually show this information (there is work for plasma packages going on already) to actually having singed contents and knowing which signatures to trust, which needs to be addressed by the community at some point.
KNewStuff3 should also finally work on Windows properly, since I got poked to fix the plugin loading troubles we had. Thanks to our kind KDE-on-Win team (and their horrible threats).
Here are the change-log additions:
- Update voting function (add overload) to take uint 0..100 according to ocs 1.6 spec
- Add comments interface to request comments, add new comments and vote for comments
- Add distribution interface to request distributions available in the server
- Add homepagetype interface to request home page types from the server
- Add methods to access home page entries in content
- Add support of icons to content (OCS 1.6)
- Add support of videos to content (OCS 1.6)
- Add summary description to content (OCS 1.6)
- Add size to download description (OCS 1.6)
- Add fields to download item for package name, package repository, gpg fingerprint, mimetype (OCS 1.6)
And the link you’ve been all waiting for:
kdelibs 4.6 will require this version soon, so be ready if you build from trunk. On the other hand, this version has been in kdesupport for quite a while, so you should be good if you build that as well. There has also been interest from Gluon and MeeGo, which makes it even more interesting to get feedback from all of you now! Packagers and all others are welcome to test and let me know if something is broken.
Unless there is major breakage, this will be released as version 0.2.0 soon.
And of course there is still lots to do, for example Ben of Forum and Sysadmin fame would like to see the forums module implemented, to bridge the gap between forums and mail (yes, evil scheming to make forums more accessible to developers that prefer mail). The task is not incredibly difficult, since there is similar code for other parts of the spec and it just needs to be adjusted. If you’re interested, let me know.
Update: because of the borked tarball there will be a next version. Expect it in a day or two.
Warning: This blog post may contain humor, it talks about unreleased magic, every second sentence ends with of course and it’s pink.
So the awesome sprint we had in Randa is long past. The topic of the sprint was something like "Fluffy is the new black – the future of the Pink Desktop". It is more pink and more fluffy than anything else.
Check out the first fluffy-tour!
I had not seen Harald since – dunno – some CeBit, about 3 years ago. Anyway, it was horrible to meet him again. We started and pink magic turned the upstairs attic at the xRandar sprint into fluff (much to the entertainment/annoyance of the others). We are both quite profit oriented and like real products that will make us famous, so we started Fluffy… our own Linux distribution, which of course is based on Hannah Montana Linux (not really) which is in turn based on that other thing that is based on Debian, that Harald occasionally works on.
Since we are serious about this project, we started by creating a facebook fan page. Of course. At the time of writing, we have over 80 fans. Join us and we’ll
rock fluff the world with… fluff! Requests for blue boys versions will probably be ignored.
So what is this "Fluffy on the Inside" with lots of Hugs and Unicorns all about? 
It is the dawn of what we think will be the favorite Linux distribution of the target audience that shall not be named here. Because some Norwegian superstar told us so. The target audience includes teenagers and developers of course. Developers just because we like them, and teenagers because it’s so pink, that it makes your teeth hurt. (Yes, I stole that quote from one of our wallpapers which we stole from kde-look. I really hope that wasn’t stolen somewhere else.)
No great design comes without careful planning. Especially the "Plasma-Ponyhof-Shell" caused us some headaches and we had long discussions about the "Movable Tree Plasma Applet" that has yet to grow up.
(note that it involves clouds, and the clouds are below the houses, what a weird word we live in)
Generally speaking, this will be the future of the desktop of course. Have fun with it. No, it’s not available yet, it’s the future. We’re getting close to releasing an alpha version. We still love the Fluffy Bunny Plasma theme and so we are working on polishing it up for current plasma versions.
Dear artists all, if you have this pink-kink bit of humor and some fluffiness on the inside, why not join us for a bit of fun? We are tolerant of experiments, as long as they fit the color scheme and have the right level of fluffiness. We even allow you to treat this as a secondary project, this is not an exclusive religion. There is also some serious fun to be had with the icons. Oh, and we renamed Dolphin to Flamingo of course!
If you happen to like styling websites, you may call yourself our web-designer, and you’ll be rewarded with the honor of working tirelessly for us under terrible conditions. We are just about to create the first public home for fluffy on the internet, it’s just that we don’t have time (besides all the packaging and other side-projects) to get it finished. Also we get lost sometimes, because the internets is so big. If you know your way around get in touch with us and your inner pink!
This guy supports us too, of course:
 I did avoid mentioning the original project name: PUKE Ultimate Edition (Pink Unicorn Koala Desktop). That is mostly because we could never find a single Koala in all we did. So the name just didn’t feel right in the end.
 no animals were or will be harmed in the creation of this distribution, all Unicorns joined of their own free will (free-beer may have helped to convince them to give up there free as in freedom free). We are well aware that Unicorns are an endangered species, therefor we think that providing them with additional turf to bounce around on is a great environmentally friendly move. We will fall back to using Unicows, if Unicorns no longer support us.
PS: Fluffy will of course be present at Linux Tag, that is if my fluffy KDE-boothistas let me present it… Sadly the project started too late to register it’s own booth, so now we have to use subtle marketing strategies, exploiting other projects. Let’s see what our friends from the other distros say.
Writing application manuals is not something I enjoy much. The last time I touched the manual for Parley, was a half-hearted attempt to update the KDE 3 material and mostly I threw out the completely outdated sections. That lead to a very thin manual that didn’t really contain much information. Now I completely agree that having a good manual is good for an application. That is why we started in coordination with Burkhard Lück to check if it would be possible to use the Userbase wiki to write a new manual. Userbase has come a long way, just this weekend there were some updates. Still, not everything is ready, the new translation infrastructure is being tested just now. So I would not encourage anyone to write their application manual on Userbase just yet.
But the other important aspect, next to technical viability is the social one. How was the experience? Mixed I must say. On one hand, working with Docbook in KDE’s SVN-repository is great because you get the benefits of a version control system. That is something I really miss with the wiki. Wikis have some sort of reversioning, but as soon as you have two people accidentally touching the same part, you are in wiki-merge-hell. That is worse than merging in subversion. You get the whole page displayed and a diff that is quite hard to read. So concurrent editing and wikis is not a good idea. The question is how often do you work on the same manual section with more than one person? This probably depends quite a bit on the project and other factors such as the moon phase. Or the current date. Like last week: we had set ourselves Wednesday as deadline since now we’re in documentation freeze and that means we should give our new fancy, fluffy manual out to translators and included in the official KDE repositories. So the night before that date we had three people working on the manual and I got scared to touch stuff because I might conflict with someone else. This required coordination on IRC, not easy… On other days, this was no problem at all, since updates were infrequent and I never got a conflict. The work has started two months ago already. Maybe we should have split it into different pages. But we weren’t sure if our preliminary structure would work out. Having all on one page helped there. The other point is the conversion to Docbook. With that in the back of my mind, I thought for a first conversion attempt, one page will be more convenient.
I disliked writing Docbook by hand, the last time I tried it. I kept messing up XML tags and the thing wouldn’t compile. I don’t know if there is a better editor for that stuff now, if so, it should be communicated (add it in the comments please). No, I don’t like writing XML, funny thing. And even more, we had Sabine on our team, and I must say, that she did a lot, if not the most work. That is totally awesome, since she’s been with KDE Education only for a short time. I would not have liked to make her learn the intricacies of producing good old Docbook, though I’m sure she’d master it. So instead we got active on the wiki and we’ll now see how we get along converting the thing to something that can be shipped with KDE. Right now we have a first conversion that lacks some links and images. We also need to figure out how to best do Docbook specific things on the wiki. I guess some more templates would be helpful there. With the latest update, Userbase got more export capabilities (if you happen to be in the right groups, for example the translators group) and a new translations framework that is somewhat similar to Ubuntu’s Launchpad. Before you run screaming though, you should try it I think it’s actually not bad and since you have the source (the actual wiki page that you are translating) in front of you, it’s not as easy to make nonsensical translations. Anne Wilson will write more about the update.
Having an offline version of the manual is important. That’s something I learned when visiting Nigeria: don’t take a fast internet connection for granted. A manual that can be shipped on CD and opened at any time for reference is incredibly valuable.
Now our joint efforts created this: the new Parley Manual for KDE SC 4.5. And we wouldn’t have gotten there in the time it took us, if we had used the traditional way. I am proud of the hard work and hours Sabine and Daniel (and I) put into it! Most of this was created in less than a week. Sure it’s not perfect, but compared to the old version it is really awesome. I would want to write it this way again. Assuming we get the infrastructure set up to convert to Docbook from Userbase pages without much manual work, I think this is a nice alternative to the traditional way. It leaves some questions unanswered still. For example what about different versions of the applications? For the next Parley version, how should it be updated, considering that this manual is for the release of 4.5 in two to three months. Users still have KDE 4.3 installed… or even older. So we need to think about that. Plasma already has one possible solution for their faq: the page always points to the latest version, with a hint that older versions are available.
Some things that I learned while working with wikis:
- It’s less painful than I thought after getting used to it a bit.
- Section Editing is a great help. If you don’t have an Edit link for each individual heading of the wiki pages, turn it on in your user settings somewhere.
- In order to add multiple images, I created the target links first [[File:Parley some file name.png]] and then I could simply click the newly created links to upload my images. Not fun, but workable.
So all in all, I liked this approach and I’m curious if we can keep the effort up and really produce a good manual in the end. Many thanks go to Anne and Ingo, our userbase experts. Thanks for the hard work on the wiki!
On a completely unrelated note, I just got a new Parley theme by mail, and I’m more than happy to have Jarle support us with his great artwork. Now we have cuddly bees, fluffy bunnies, businessy grey and science fiction:
Ready for takeoff! You rock!