I’ve been asked a few times to post the slides of my talk online. Lets hope we’ll have the videos soon as well.

The slides are now available on SlideShare.

There are quite a few nice talks in the C++ track of Qt Dev Days this year. So many that I don’t expect to move away from that room at all.

I’ll be talking about a fun and clean way to work with asynchronous APIs on Wednesday at the Cafe Moscow in Berlin. I hope I will not get sleepy after lunch.

The talk will be about dealing with asynchronous API using futures (QFuture, std::future, boost::future, QDBusPendingReply…) and continuations. It will be about inversion-of-control, variadic templates, lazy evaluation, functors etc. There will be a few c++11 headache-inducing features demonstrated.

See you in Berlin!

The summer is over, but we are only at the beginning of the wonderful Plasma2/KF5 voyage. So, what did I do so far, you ask?

A few things.

Shell switching

For some reason, I always start singing “Shell switching with my two favourite allies” when I get to think about this new Plasma mechanism.

This was the main part of my project for the summer - making the infrastructure to let Plasma adapt itself based on the environment it is running in. For the details on this, check out “Switching the Plasma Shells” post.

The main, and most fun side-effect of this work is that from now on, any QML-based application is able to access the hardware information provided by the uber-awesome Solid library, while it got even more hardware support - namely, it now detects the input devices under udev-based systems.

Activities for the new age

Porting KActivities to KF5/Qt5 was not supposed to be a part of the GSoC. The reason it came to be was that is it much more important for the rest of the development process of Plasma, than some of the originally planned tasks. Though, those are mostly done as well, but will be merged at a later stage - no point in putting finishing touches to something that is still under heavy development.

For more information about the changes in KActivities, see “KActivities for Qt5/KF5”.

This is just a short one.

What would you say if I told you that you can have an indent-like command that actually understands your code?

And that it has plugins for vim, emacs and a few other editors/IDEs that will allow you to reformat your code on the fly?

If you would say ‘Yes please!’, just visit this page and enjoy: Clang Format.

It works quite nicely, except that it doesn’t really speak Qt. Qt’s macro-keywords like Q_SIGNALS, foreach and similar will still require your manual formatting.

KActivities has been ported to Qt5. The main service and the core library work without a glitch.

There are a few things left to finish like the Nepomuk integration and virtual desktop switching, but those will have to wait for the dust to settle in the required libraries.

API changes

The porting has not been only about making it compile on the new platform, but was a last chance that I’m going to have for a long time to fix the API of the library, by removing the deprecated methods, and making the interface asynchronous.

The old API was created with one thing in mind - to be as simple as possible for the user. Unfortunately, that meant not caring much about the fact that the clients have to communicate with the activities service via DBus which can get slow at the times and block the client.

Now, the library took a different path - it still has a similar (95% same) API to the old one, but the behaviour has changed a bit - it will never block. As soon as you create an instance of KActivities::Info or Consumer class, it will start syncing its internal one-per-client-application cache with the service.

It is up to the client to test for the status of the synchronization before trusting the values the library returns. This is essentially the same check that the clients should have already be doing in the old version - checking whether the activities service is running at all. The only change is that the status can now be ‘Syncing’, and not only ‘Running’ and ‘NotRunning’.

What does it mean for QML users

Since everything is exported via well-behaving properties, you don’t even need to care about the state of the synchronization - just connect something to a property and relax - the value will be set as soon as possible.

What does it mean for C++ users

You just create an instance of Consumer or Info and:

1. Cover the case when the results are not valid (if the service is not running, or the data has not been synced yet) - In this case, the client gets a single activity with no name and a null uuid (like before).
2. Hook into the signal which will tell you when the data is ready (or just into the signal of the property you want)

Advice: At least one instance of Consumer/Info should be long-lived for best performance. For heavy activities users like plasma and kwin, it would be the best if one Consumer instance was always-living.

A bigger change

The only class whose API has changed dramatically is the Controller, a class that should only have a few users - activity switching/creation applets and similar (aka Plasma and its children). All methods that were blocking are modified to be asynchronous by using non-thread-based QFutures.

No change

For the users of KActivities::ResourceInstance (Gwenview, Okular, Calligra etc.), no changes are needed - the class API was already perfect. :)

Honestly, I can not wait for Plasma 2.