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:
- 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).
- 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.
