Updates all over

Although I promised I would have blogged more often, I find myself to be always very short on time to do that, and always in need of writing “wrap-up” posts to keep up with everything I do –  I guess you can live with that. While writing this post I am stuck in Frankfurt Airport waiting for a train, so why not writing a blog post after quite a while. But let’s cut the introductory words and let’s get straight to the point(s).

Big updates in KDE Telepathy
Last days I have been working very hard on KDE-Tp and Tp-Qt, bringing some big changes and improvements to both projects. As Martin already blogged, I took over a big part of the porting to the new Tp-Qt. One of the main reasons why we did that was some patches I have been pushing to it. First of all, thanks to the new Tp-Qt, we are now able to correctly detect action messages, such as “/me” (David already has a patch about that). High-level DBus tube support is soon to be merged as well, which will eventually allow many applications to take advantage of the feature in an easy way.
This is not everything though: the underlying architecture has undergone quite a change due to the fact telepathy-common-internals is now a private library used by all of our projects. Which means: if you want to compile KDE-Tp master, which will eventually be KDE-Tp 0.3, you will now need Tp-Qt master and telepathy-common-internals right before building anything else. Our final 0.3 release is obviously planned after the first release of Tp-Qt 0.9, so our packagers can stay assured we won’t rely on snapshots.
I have also been lucky enough to catch Nuno in San Francisco and take advantage of his awesome UI Clinic. I got some useful feedback I still need to reorganize and communicate, but it’s been indeed very interesting and useful. And I also learned something more about how to spot (and what are) UI design errors, which is always a good thing.
So, what’s coming up? Lots of things. The 0.3 release will mark the move of KDE-Tp out of Playground and into Extragear, leading the path towards our first, awesome stable release and towards starting to spread our software to all distributions near you. 0.3 should still be considered beta, but we are getting there. Our effort is complex and geared towards a stable and long-term solution, and I can assure you won’t regret the wait.
More stuff in 4.8 Power Management

If you are a loyal reader (you are, aren’t you?), you are probably aware of the big changes the Power Management infrastructure has undergone in 4.8. Before the final release, I still had the time to fix a few bugs (a lot of them were long standing from previous KDE versions, so you should indeed be happy), and to implement a few new small things. One of them is “supported actions”. What does it mean? From 4.8, individual actions are able to advertise if the system supports them. If that is not the case, the action won’t activate itself and won’t even show in the UI.
To give you an example, suppose your monitor does not support DPMS (unlikely, but well). Before this change, the “Turn off Screen” action would have appeared in the configuration UI and loaded under the hood. From 4.8 on instead, the config UI will not expose the action at all in the configuration, and the daemon will simply refuse to load it. And since the check is always done at runtime, you will be always 100% sure to see only the actions your system supports.
This is a huge step forward towards the integration of more complex and hardware-specific actions, which can now be shipped by default but be exposed only on systems which support those. It will be extremely useful on mobile devices, like in the Plasma Active land, but don’t underestimate the impact such a thing can have on desktops as well: my friend admiral is coding an action to allow automatic switching of graphic cards on systems which have this feature (like my Macbook Pro) and support it. This is quite late for 4.8 of course, but thanks to the new architecture it can be shipped into a separate package for people who cannot wait. It will probably make it into workspace in 4.9 though.
Of course, this also means if you have hardware which supports particular power management features, you should really look into writing a new Action and finally getting rid of those scripts. Although writing an action is really straightforward, I indeed plan to write a decent guide on Techbase for interested people. As I had many cries for support of particular powersaving features in different video cards, be aware that you no longer have an excuse to prevent you from contributing!
Catch me around

If you want to catch me around in the next few months, in January I will be in Ballarat at linux.conf.au, talking about how to build social applications with Telepathy and Qt, and most probably also on multithreading features in Qt and how to get the most out of them (yes, two separate talks of course). Otherwise, I will very likely be at FOSDEM in February to meet old and new friends. If you want to catch me for a beer, be my guest. Also, I will be going around with some ALERT leaflets and will probably give out a lightning talk about ALERT and KDE’s involvement in that.
And that’s all for today, my train’s about to arrive. See you next time.

~ by Dario on 12 December, 2011.

10 Responses to “Updates all over”

  1. Sounds awesome 🙂

  2. Supporting graphic card switching would really be awesome ! How do you achieve that ? Doesn’t X needs to be restarted ?

    A bit off-topic but what distribution are you using on your MacBook Pro ? Which MacBook Pro version is it ?

    • In some cases yes at the moment, in this case we’ll provide a different solution of course.

      I am running Kubuntu ATM, everything is supported and works like a charm. My MBP should be a 7,1 (late 2010)

  3. It’s awesome to see KDE Telepathy blogged as much as it is. Are there any plans to replace Kopete on KDE SC in the future? It would seem like logical step foward after having stable releases and moving to Extragear. Kopete probably isn’t going to receive any futher developement and having somewhat broken and inferior IM client on SC by default doesn’t sound that good. If KDE Telepathy were to keep its own release schedule what can we expect to happen to Kopete in the future?

    • Yes, the relationship with Kopete is clear and KDE-Tp is already accepted as the future replacement for it. Kopete will eventually be deprecated once KDE-Tp is in a gold state.

      Regarding Extragear and KDE SC, I guess it will strongly depend on how the 3rd parties we rely on will behave. To be honest, I see it difficult to put KDE-Tp in KDE SC due to the moving dependencies in the near future.

  4. “And since the check is always done at runtime, you will be always 100% sure to see only the actions your system supports.”
    Oh how much I prefere to have those grayed out but still visible. But I do suppose it could clutter too much the interface whic would became full of unused entries.

    • One question regarding the “supported actions” solution. With my laptop I connect to different external displays depending on which customer I work for and which location I am at. Will the settings which have been created when a certain action is supported be remembered until the next time it is supported? I can see some disadvantages with such a “memory”, but a lot more disadvantages with all settings being lost.

      • Replying to you both: of course the action will retain memory of the configuration, you will not even notice what’s happening. In this case we’ll probably force a recheck of supported actions when connected displays change when it makes sense, but this is part of the ongoing KRandR effort, which is close to being complete.

        Regarding the grey-out of the actions, consider that DPMS is a very special case, whereas the rest will rely on having some particular hardware installed, hence not really something you want to see

  5. Some actions, if hidden, will confuse users. I know they’ll confuse me. “Now, where is the option to do foo… *spends 15 minutes scratching head, and browsing the web for where to look* … “oh, this external monitor does not support it; or, the driver update screwed that feature!”

    • I see your point. In the near future, we will probably add these things to system info or in a dedicated section somewhere else to clearly show to interested power users which features are enabled or disabled in your system, and why. But this was way too complex and long to be part of 4.8. Also, as I said above, the action is simply disabled, but the configuration is always retained (to cover the case a driver update broke DPMS support)

Leave a reply to Dario Cancel reply