Archive for the ‘KDE’ Category

CMake Library Tutorial

16th August 2015

Interested in writing or maintaining a KDE Framework? Getting the build system right for a Framework, or indeed any other library, is not trivial. I’ve just finished writing a tutorial to help you do just that, though. It can be found at the CMake tutorials page on TechBase, and guides you through (an idealised version of) the KArchive buildsystem.

Comments, feedback and questions on the tutorial are welcome – here, by email or on the discussion page of the tutorial.

Akademy 2015

30th July 2015

I’m just finishing up a week spend at Akademy, the annual conference of the KDE community.

AGM lunch break

We started last Friday with the AGM of the KDE e.V., the legal entity that deals with the financial and other legal aspects of KDE.

Working 1

After that, we had two days of talks, and then from Monday onwards we’ve had “birds of a feather”, or “BoF”, sessions where people working on or interested in similar things get together to discuss things face-to-face.

I have visions, should I go see a doctor?

It’s been great fun, and I’ve really enjoyed seeing people I’ve met before again and meeting people I’ve only known through IRC and blog posts or have never even come across.

Question time

The organising team have done a fantastic job: we’ve had free busses running from our accommodation to the venue, video recording of talks (which I’m sure someone will post about soon), easy to access food, two parties and people always on-hand to provide information.

Smart Tech and Sensible Tech

There have been announcements of new technologies, talks about community things like how to write a vision statement or what artists are doing with Krita, technical talks about things like how to optimise your program, talks about development methodologies and more.

Akademy Award winners

Personally, I’ve taken the opportunity to start improving our CMake documentation, including writing and planning new tutorials. I’ve also been working on some Extra CMake Modules things at the request of David Faure, looking at accessibility things with Frederik Gladhorn and trying out the upcoming release of Plasma.


I’ve had great fun taking lots of photographs this Akademy, and have been uploading them all to Flickr.

Wall sitting

I’m not the only one, either – you can find other photo sets linked from the Akademy wiki.

Find a rock, climb it

I’m about to catch a flight home, but I very much hope I can make next year’s Akademy as well.

View from the Torre de Hércules

Buildsystem BoF at Akademy

8th July 2015

I’ve just booked a room for Tuesday afternoon at Akademy for a couple of CMake / extra-cmake-modules BoF sessions.

The first part is for people who want support hacking the buildsystem of their own projects. Not sure of the best way to migrate to extra-cmake-modules as part of your shift to KF5? Getting “deprecated” or other CMake warnings you want to resolve? Can you think of something really useful the buildsystem could do in your project, but you don’t know how to do it? Come along, and I (and hopefully others) will be there to give you a hand. Likewise, if you feel comfortable writing stuff in CMake, and you want to help other developers, come along to lend a hand – you don’t need to be an expert!

The second part is for people who want to contribute to extra-cmake-modules. If you have some CMake code in your project you think other projects will find useful, or you have ideas for improvements in the existing modules, come along and pitch in.

Help wanted: Photoshop

1st March 2015

As part of KDE Frameworks, we have a collection of QImage plugins that allow Qt applications to read various types of image files not natively supported by Qt. I’ve recently overhauled the one that reads Photoshop images (PSD files) but, without access to Photoshop, I have no way to create images that test the code. The one test image I have, I created using the Gimp, which is less than ideal when I want to test compatibility with Photoshop itself.

So, if you have access to Photoshop (Photoshop Elements might be sufficient, I’m not sure) and would be willing to make some test images (in pairs – one PSD, one PNG) of various specific configurations and in various save formats, please do get in touch (alex dot merry at kde dot org, alexmerry on IRC, or just post a comment here).

To the extent that the simple images I require would be copyrightable, you would need to be willing to license them under the LGPLv2+ or a permissive license (CC-BY-SA would be fine, for example).

New installation variables

13th January 2015

I noticed a while ago that the CMake installation variable names used by KDE projects (defined either in kdelibs or KDEInstallDirs in extra-cmake-modules) are inconsistent with what GNUInstallDirs, for example, uses. The traditional variable names are things like BIN_INSTALL_DIR and CMAKECONFIG_INSTALL_PREFIX, while GNUInstallDirs defines things like CMAKE_INSTALL_BINDIR and CMAKE_INSTALL_DOCDIR.

In an effort to make the installation variables more consistent and compatible with GNUInstallDirs (for the ease of packagers and developers alike), I introduced GNUInstallDirs-style variables to KDEInstallDirs – this included the variables defined by GNUInstallDirs and other ones beginning CMAKE_INSTALL_. These were kept in sync with the old-style variable names.

Both of these styles of variables have namespacing problems: the ones starting CMAKE_ tread on CMake’s namespace (so CMake could potentially define one of those variables that doesn’t appear in GNUInstallDirs to have a different meaning), and the old-style variables are very generic and could conflict with another CMake module. Neither of these are likely to be an issue in reality, but it is good practice to respect namespaces in third-party modules.

KDEInstallDirs now primarily defines variables starting with KDE_INSTALL_ (which corresponds with the module name). The old-style names and all the CMAKE_INSTALL_ names that do not also exist in GNUInstallDirs are deprecated, and can be disabled entirely (see the documentation). It is possible to disable the variables that appear in GNUInstallDirs as well.

This appeared in extra-cmake-modules 1.6.0, but that version had some flaws (for example, it would break if you used both GNUInstallDirs and KDEInstallDirs in the same project, which was a major oversight), so you should use 1.6.1 instead.

There is a script in the kf5 directory of the kde-dev-scripts.git repository to port your CMakeLists.txt files to the new variables: Just run it in a directory with a CMakeLists.txt file.

return EBUSY;

8th September 2014

I just want to apologise to those of you who are waiting on me for Review Requests, etc. Last month was quite busy for me, and this month is even more so – all good things, such as friends getting married, but all time-consuming. On top of that, Akonadi and the server I use for KDE-related email have decided they aren’t talking to one another, which makes it that bit harder to deal with (due to having to log into, and then deal with the interface of, webmail).

I’m expecting life to calm down considerably in October, so hopefully normal server should resume then.

Qt5 Pretty Printers for GDB

4th June 2014

If you’ve ever debugged a Qt program in GDB and been frustrated when attempting to print a QString gives you an unhelpful result like

$1 = {d = 0x6e7c40}

then kde-dev-scripts has some useful tools for you. For some time now, there has been the kde-devel-gdb script, which you can include in your ~/.gdbinit. This gives you commands like “printq4string” and “printq5string” which will dump the actual string contents of a QString.

However, GDB 7 has the ability to add pretty-printers written in Python. This means that you can control how a value is output when you use “print” and when backtraces are printed. So “print someQString” will actually write out the string for you.

The gdb directory of kde-dev-scripts now has some of these pretty-printers for Qt5. Currently, it covers most of the main value classes and collection classes in QtCore (QByteArray, QString, QStringList, QList, QMap, etc). QHash and QSet are the most notable ones that are missing.

To use these pretty-printers, you either need to source the “” file in your GDB session, or use the “” script to generate files that will allow GDB to auto-load the printers when it loads the Qt5 libraries.

I plan to eventually submit these to Qt, so that pretty-printing of Qt value classes will work out of the box. For now, do let me know if you run into any issues with them (don’t forget to compile your application with debugging symbols!), and feel free to extend what’s there, or use it as a template for some Qt4 pretty-printers.

MPRIS2 and the Music Player Daemon

17th May 2012

If you tend to want to keep your music running when you log out, or control your music playing on a desktop machine from a laptop, for example, you may well use the Music Player Daemon (MPD).  If you use Ubuntu’s Unity desktop or KDE’s Plasma desktop, you may well wonder how to get the Ubuntu sound menu or Plasma’s Now Playing widget to talk to it.

Both of these use MPRIS2 to communicate with media players.  MPD, however, does not have an MPRIS2 interface.  Even if it did, it would take a bit of work to be able to use it from another computer.  What you need, then, is a “bridge” of some sort to translate.  One such possibility is mpDris2 (which, I hasten to point out, I haven’t tested).

You would run such a bridge on the computer you want to control MPD from, and point it to your MPD instance.  And voilà!  Every MPRIS2 client application that you run can talk to MPD, without knowing anything about the MPD protocol.

If you just want a headless music player on your local machine, though, you can always use Raven, which talks MPRIS2 natively.

New Now Playing Plasmoid, MPRIS2 dataengine

11th May 2012

One thing that will be in KDE Plasma Desktop 4.9 is a new version of the Now Playing widget.  Based on QML, it works much better, especially on panels (where its design is based heavily on my favourite KDE-3-era applet, kirocker).

Now Playing on a panel

In the background, it uses the new mpris2 dataengine.  This exclusively supports MPRIS2-capable media players (which these days is most), and doesn’t include any hacks to support XMMS 1, for example.  JuK and Dragon have both gained MPRIS2 support for the 4.9 release, and Ubuntu’s sound menu uses MPRIS2, which is compelling many other media players to support it.

Now Playing on the desktop

The result is a cleaner, more reliable design, and completely asynchronous behaviour, so it will use less power and (unlike the old nowplaying dataengine) it should never cause your desktop to freeze due to a badly-behaving media player.

Now Playing with the mouse over

The old nowplaying dataengine is still there (and will be until KDE Plasma Desktop 5 is released), but should not be used for new widgets.  Instead, you should use the mpris2 dataengine, and I highly recommend porting any existing widgets to mpris2 as well.

Overall, I’m really pleased with the design of MPRIS2, which allowed me to create the mpris2 dataengine with a minimum of fuss, and allowed for widgets to implement a seek bar without querying the media player once or twice a second to find the current position (and not take the performance/power hit if they didn’t care about the current playback position).

MPRIS2 Support in NowPlaying

10th November 2011

Do you recall NowPlaying?  The dataengine/widget pair for Plasma that tells you what your media player is currently playing, and allows you to control it?

The Now Playing widget (with an old theme)

Well, now it supports MPRIS2.  What does this mean for you?

Well, probably not much right now.  Juk doesn’t support MPRIS2 (although I intend to change that for 4.9/5.0), Amarok worked before (although it should use marginally less power with MPRIS2 rather than the old MPRIS interface), VLC doesn’t support MPRIS2 (yet; version 1.2 will).  A handful of other players support MPRIS2, though, including the Raven Music Server.

The main thing, though, is that support for MPRIS2 is increasing in media players, partly because of Ubuntu’s adoption of it as the mechanism for its sound menu to talk to media players.  Spotify now supports MPRIS2, for example.  And now the Now Playing widget can support them.

MPRIS2 has many advantages over the original MPRIS specification, not least of which is not having to query the media player every second for up-to-date position information.  As a result, the nowplaying dataengine will prefer the MPRIS2 interface to the MPRIS interface for a media player that offers both.

The only quirk to be aware of is that Amarok’s MPRIS2 support isn’t quite right in the 2.4.x series, and this will affect a couple of features of the Now Playing widget (seeking and enabling/disabling of the next/previous buttons); this shouldn’t be an issue though, as these problems are fixed for Amarok 2.5, which will be released before KDE Plasma Workspace 4.8.


Get every new post delivered to your Inbox.