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!
Daniel already wrote about the KDE Education Sprint in Randa and some of the news in Parley land. Harald and I recorded a screen-cast with a Fluffy Parley that should have never seen the light of day. That pink monstrosity surly seems to have taken a special spot in our hearts And yes, we shamelessly stole from other well-known sources. That includes the Fluffy Bunny Plasma theme and the KBlocks Pink Bunny theme. Sabine reports that her daughter is in love with Fluffy already. What is it with all these bunnies anyway? Could someone out there please draw me a Pink Unicorn instead? Bonus points if you also draw a nice Unicow. I will buy beer for that.
Since we had so much pink now, I’ll stick to the boring stuff that also happened. Our plans for Parley included separating the graphical part of the vocabulary practice and the back-end that manages the whole show. At some point we noticed that using a simple painter to draw random images in the background of the app was fun. Of course it was clear that just using a bitmap there would not be a good idea, that’s why all of KDE Games and some Education apps use svg-magic instead. Just like our beloved Plasma. So after sitting down and trying to grab the best pieces from all of these, we have something to show. Of course much more work went into polishing what goes on behind the scenes. But that’s hard to show… Daniel and I started to first plan this update at Akademy last year, almost a year ago.
Parley still carries around some of the luggage that KVocTrain had accumulated in KDE 3 times. KVocTrain had a ludicrous amount of settings and would let you enter lots of details for each individual word. I was always reluctant to saw away features there. The funny thing though, was that most of the data you could enter for your vocabulary, was just plain useless. If it doesn’t show up in a learning session, what’s it for then, eh?
Some of this madness has been cleaned up for KDE SC 4.5. Now it’s not pointless any more to add pronunciation to a word for example. Many features now work the way you’d expect. The recent sprint motivated us to sit down and polish lots of things. So far the early tester feedback has been very positive. We knew since long that the practice part needed lots of love. Some of the code was basically untouched since KDE 3 times. Many things were not working.
One prominent example was conjugations, where none of the progress was saved. Not ever. So it was basically impossible to learn conjugations with Parley in any sensible way. Now finally, Parley lets you practice your conjugation skills, only shows words that you should actually work on and gives sensible feedback.
With the working practice modes and the svg featured additional fluffyness, much of what I wanted Parley to be has come a step closer. Learning vocabulary is not the most fun thing in the world, but at least it doesn’t have to look horrible! I’m very happy that I was in touch with Jarle Akselsen already, now we have a great bee theme for Parley. No, I assume bees are not fluffy, but the bee theme is the best looking we have so far! You heard of the Bunnies already, they have more value in that you can shock your friends with them I’m curious to see what other themes will show up. Of course we use get hot new stuff to let you grab new Parley themes as they pop up
Of course no KDE-related blog post without a call for help. Currently we’d appreciate one or two more themes, if anyone is interested, we have documentation inside one svg. The other part that is painfully obvious is the lack of a good manual. We’re currently writing on it, but I for example wasn’t born to write manuals (something deep inside me tells me that). So if you feel like improving our writing, we’re currently working on userbase.kde.org/parley and will convert that to a proper doc-book format once we have some good contents (freezes say, that would be tomorrow).
Update: When doing screen shots past midnight, there is a danger of messing things up, such as German grammar… "Ihr seid" it is of course.