Posts Tagged ‘Plasma’

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

Screen locking with the Plasma netbook interface

4th September 2011

If you are using the Plasma desktop on your netbook in “netbook mode”, you may have noticed that screen locking (in all its forms – the Ctrl+Alt+L shortcut, typing “lock” into search-and-run, and automatic locking when suspending to RAM or when the screensaver starts) no longer works.  This is because KRunner doesn’t run in this case, and KRunner is (somewhat bizarrely) responsible for activating the screen locker.

The proper solution to this (and the one that should be implemented for 4.8, hopefully) is to get KWin to manage screen locking.  After all, it knows best when it comes to managing the screen.  But, until then, you can use the quick hack I came up with: putting screen locking into a kded module.

This works quite nicely with existing installations, as you can just compile and install the KDED module and be on your way.  One caveat: KRunner will retain the shortcut.  Once you’ve started the module for the first time (either from the Service Manager kcm or by logging out and in again), you will need to go to the Global Keyboard Shortcuts kcm and set Lock Session shortcut for KDE Dæmon.

Run the following commands to do this (you’ll need cmake and automoc, as well as development packages for Xorg and kdelibs):

git clone git://
cmake ../kscreenlockmgr -DCMAKE_INSTALL_PREFIX=$(kde4-config --prefix)
sudo make install

Or, if you’re on ArchLinux, just grab kscreenlockmgr-git from AUR.


8th July 2009

It’s been a while since I posted. Such is life.

I’m really enjoying my first Akademy. I managed to forget a power adapter to convert between my British plug and the European sockets, but Nuno lent me one for a few days. I now have to find my own, though, as he went home today.

So, the conference. The keynotes on Saturday morning were really good. I recommend watching them when the videos are online (which they may be already). Of course, there is some furore over Richard Stallman’s talk, but I think that was always expected.

Yesterday was the KDE e.v. meeting, which I didn’t go to (not being a member of the e.v.). Instead, I slept in (sleep has been in short supply), went to the beach, and hacked. I put together a small plasmoid (87 lines of javascript) to show some controls for a media player. The idea is that you can put this on an auto-hiding panel on your desktop so that they don’t take up screen real estate, but are easily accessibly just by moving your mouse. The other half of the job, of course, is to do one that displays information. Then you can have the information about what song is currently playing permanently visible, and the controls only appear when you want them.

Today we had a very productive discussion on moving KDE to Git. The aim (if everything goes swimmingly) seems to be to move before KDE 4.4 goes into freeze. Amarok is intending to move very soon, though.

Speaking of Amarok, we’ve been sitting in one of the labs discussing things since the Git BoF. It’s amazing how much gets decided how quickly, especially when you’re used to deciding things on mailing lists. This is particularly true for user interface decisions. I’m expecting great things from the next release of Amarok.

What’s Playing, Doc?

17th May 2009

So, I was round at a friend’s, and he was playing with Amarok and the Plasma widgets screensaver, and wanted a way to see what was currently playing when his computer was locked.  Of course, I pointed him towards the Now Playing applet, but it was overkill for what he wanted – he didn’t want the buttons, or the sliders – just a display of the current information.  Well, I was in the mood for playing, and it took me about 15 minutes to construct a javascript plasmoid, most of which was spent researching how to use data engines from them.

The code I left him with was:

layout = new LinearLayout(plasmoid);

label = new Label();
label.text = 'No player'

plasmoid.dataUpdate = function(name, data) {
    label.text = 'Info:\n';
    for (var key in data) {
        label.text += key + ': ' + data[key] + '\n';

plasmoid.dataEngine("nowplaying").connectSource("org.mpris.amarok", plasmoid, 500);

This was in a file called “main.js” in a subfolder called “contents”. In the plasmoid folder (the folder containing the contents folder), I also put in a metadata.desktop file:

[Desktop Entry]
Name=Simple Now Playing
Comment=Now Playing as Matt likes it
X-KDE-PluginInfo-Author=Alex Merry
X-KDE-PluginInfo-Email=alex.merry [SPAMNO]@[SPAMNO]

Now it was just a case of calling plasmapkg -i . from within the plasmoid directory, and the simple widget was installed. This produces the following:


Of course, this will only work with Amarok, and doesn’t respond to Amarok being started or quit. That’s OK, it’s not much more work to deal with that:

layout = new LinearLayout(plasmoid);

label = new Label();
label.text = "No player found";

function firstSource() {
	var sources = plasmoid.dataEngine("nowplaying").sources;
	if (sources.length) {
		return sources[0];
	} else {
		label.text = "No player found";
		return '';

plasmoid.dataUpdate = function(name, data) {
	if (source == name) {
		label.text = 'Info:\n';
		for (var key in data) {
			label.text += key + ': ' + data[key] + '\n';	

source = firstSource();

npDataEngine = plasmoid.dataEngine("nowplaying");

npDataEngine.sourceRemoved.connect(function(name) {
	if (name == source) {
		source = firstSource();
		if (source) {
			npDataEngine.connect(source, plasmoid, 500);

npDataEngine.sourceAdded.connect(function(name) {
	if (!source) {
		source = name;
		npDataEngine.connect(source, plasmoid, 500);

if (source) {
	npDataEngine.connectSource(source, plasmoid, 500);

Of course, it’s not much work to only show the things you’re interested in, but this covers the interesting parts of the plasmoid.

Interesting note: it appears that if you replace the line label.text = 'Info:\n'; with label.text = '';, the subsequent calls to label.text += ... don’t work – you just end up with a blank label.

Why silence is better than 10 reasons

31st March 2009

This is a deconstruction of 10 reasons why GNOME is better than KDE, which is pretty obviously a piece of flame-bait. Wallen basically says as much at the start of the article. But I’m in the mood for dissecting arguments.

I would like to say right now that this is not a “10 reasons why KDE is better than GNOME” article. That would be inane. I have many GNOMEy friends, and no intention of trying to convert any of them. Anyway, I’m pretty sure that any one of you can come up with both 10 things KDE does better than GNOME and 10 things GNOME does better than KDE.

Instead, this is an excercise in deconstructing an argument. Critical thinking, if you will. Because Wallen completely failed to come up with 10 reasons for anything.

So, lets start at the top. “1. KDE 4”. I’m not really sure there’s anything to say about this, other than that the entire paragraph is simply a collection of unsupported statements (with no narrative to connect them). He doesn’t provide a single example to support any of his attacks (including ‘KDE was (and is) the first-ever “Microsofting” of the Linux desktop’ and KDE 4 was “painfully worthless”). OK, let’s move on.

“2. Start Menu”. Well, using Microsoft terminology when ‘”Microsofting” the Linux desktop’ was mentioned in the previous paragraph was probably intentional, but not helpful to any argument, really. We get “It should be pretty obvious” and “It should also be fairly obvious” almost straight off the bat. Chalk one down for unsupported statements.

There’s possibly a valid criticism about Kickoff and the lack of KDE 3’s quick menu applets being made in here, but it’s difficult to disentangle from the ad hominem attacks. And he probably has a point about discoverability of things like how to change the menu to “classic” style. Not that I believe such a thing is both possible and discoverable in any other desktop, so I’m not sure it really advances his original argument about one desktop being “better” than the other.

In “3: Nautilus vs. Dolphin”, he actually doesn’t compare Dolphin to Nautilus. He compares Dolphin to Konqueror, and the latter still functions as a file manager in KDE 4. OK, that first statement wasn’t entirely true. He says that Nautilus is Dolphin, but stable (and makes a reference to Dropbox that appears to bear no relation to anything else). That brings the number of potentially valid criticisms in this article up to about 3 (the arguments in section 2 were hazy).

He also says that users will find most of the features of Dolphin useless. And justifies this by mentioning one feature, possibly two if you count rating and tagging separately (Dolphin has more than three features, right?). One black mark next to “generalising from the specific”. And possibly “presenting exaggeration as fact”.

“4: Foundations”. I’m not sure why he picked this title. Qt 4 gets a passing mention (in the first sentence), and the only thing that is said about GTK+ is that there will be a version 3 soon. I guess you’re supposed to infer from context that this will break backwards compatibility. He also implies (but doesn’t say outright) that the port to Qt 4 was largely or solely because of the potential for a windows port. The reason was in fact because Qt 4 had a much-improved API, and Qt 3 was shortly to become unsupported by Trolltech (as was).

This section also has a fallacious comparison between GNOME 2.24, with it’s forward compatibility flags, and KDE 4 (a more sensible, although still not entirely accurate, comparison would be the as-yet-unreleased GNOME 2.30 with KDE 4). The thing is, he could probably have made a decent argument along the lines of GTK+3’s migration plan being better than QT 4’s, but he completely failed, largely by getting sidetracked with the Window port non-issue. Oh, and I’m really not sure what resources he believes are being diverted from the main project to work on the windows port. Or how KDE might go about forcing those people who insist on getting their favourite applications to run on Windows (as they did even back in KDE 3 days) to give up such an unworthy pursuit and return to the warm, fuzzy and – above all – morally superior fold of free unix-based operating systems.

Sorry, I seem to have had a nasty attack of sarcasm there. I’ll try not to let it happen again.

On the other hand, section four is possibly the most well-constructed section in terms of arguments. I had to remove the underpinning (the assumption that the move to Qt 4 was all about Windows) before the rest of the structure of the argument collapsed.

Oddly enough, in “5. Resources”, his one concession to KDE 4 (using fewer resources than KDE 3″ is highly disputed among those who measure such things in KDE. The rest of this section revolves around his decidedly unscientific comparison between the memory usage of KDE and GNOME (given the content of section 10, one has to assume that this means default installs of Fedora 10, but there is nothing to say so). He gets a difference of 10Mb when both desktops use more than 1.25Gb of RAM. That’s a 1% difference in memory usage. Apparently this means that “GNOME requires less hardware to run”. I’m not entirely sure where he intends to buy exactly 1.27Gb of RAM from (which, it seems, will run GNOME but not KDE – providing you don’t launch any other applications, of course). But, seriously, 1% is not a significant difference. Given that his measurement almost certainly includes kernel caches, and is probably based on the default installations of one particular distribution, it is almost certainly completely dwarfed by the error rate.

“6. Clutter”. Half-way there. Showing the desktop folder, it seems, is cluttering the desktop. Despite this being what just about every other desktop implementation out there does. *shrugs*. Let’s play along, then. This is a reasonable argument, but made at the expense of ignoring the facts. The major one is that it takes one click to remove the item he’s complaining about. So, a second argument that required me to actually respond with a fact, rather than dismantle purely on the basis of fallacious reasoning.

“7: Customization”. Again, lots of unsupported statements. GNOME is almost infinitely customizable (how?); KDE 4 locks you down (in what way?). Nowhere does he give even one example of something that GNOME allows you to customise that KDE doesn’t. He talks about mouse menus, but this appears to be a comparison of KDE 4 with KDE 3 (and I’m not sure what he means by “mouse menus”, either). And saying that you can’t change the look of something except by using the very mechanism that allows you to change its look (theming, in this case) is… true. But completely besides the point.

“8: System Tray overkill”. This is a comparison of the default setups on Fedora 10, not of the default setups of the desktop environments in general. So this is an example of generalising from the specific.

Apart from that, not all of the items he lists are actually part of the system tray (the clock, for example, is actually an applet, not a system tray icon). And desktop shells can’t do anything about the system tray other than display what programs offer. The applets, on the other hand, can be removed – both in GNOME and KDE. The one valid argument in this is about the loading time of the system tray. I think that’s 4 valid arguments (that couldn’t be immediately dismissed by stating a single fact) in total so far.

“9: Default applications”. Konqueror has been the default web browser of KDE (although not necessarily of any given distribution’s installation of KDE) since KDE 2, as far as I’m aware. So quite where he got the idea that Konqi has suddenly moved into this role, I don’t know. KOffice 2 hasn’t even been released, so I doubt it’s the default anywhere (although I’ve heard that Fedora can be pretty bleeding edge). And Firefox isn’t the default browser in GNOME, it’s Epiphany. Although that does use the same rendering engine as Firefox. And I’m not sure GNOME really has a “default” office suite. Basically, Wallen is confusing desktop environment defaults with distribution defaults. Repeat after me: Fedora is not representative of all Linux distributions.

So that’s a mix of generalising from the specific and ignoring certain facts.

“10: KDE = Vista?”. I can sum this up as “people don’t like Vista, and I think KDE looks like Vista, ergo KDE sucks”. Unfair? Well, maybe. But saying that you can make KDE look like Vista by installing the right theme (I assume Emerald refers to a theme) does not an argument make. And I know that Vista is famed for being unstable (slightly unfairly, I have to say), but all software goes through an unstable phase (except possibly TeX) and that doesn’t make it like Vista. Or unlike Linux (as in GNU/Linux, not the kernel). And he still hasn’t presented a convincing argument (or an argument at all, for that matter) for KDE 4 not being flexible. Plasma was designed to be much more flexible than kicker/kdesktop, and Wallen has failed to provide any evidence that it has failed in those aims. Not that I’ve presented any evidence it has succeeded in them, but my aim is not to prove the worthiness of KDE 4 but to dismantle Wallen’s arguments.

Finally, Wallen makes the common mistake of assuming that KDE 4 = Plasma. Well, OK, Dolphin got a mention. Yes, it’s probably the most user-visible component of a KDE 4 desktop session, but KDE is primarily a software platform, and includes a desktop shell as part of that. So that’s generalising from the specific again.

Well, I found four reasonable arguments in there, plus a few more that were recognisable as arguments even if they could be countered with a simple fact (I can forgive people for not knowing all the pertinent facts :-P). But most of the rest didn’t form any coherent argument at all.

I think that’s enough from me. I suggest you all go read about logical fallacies now, so you can give fancy names to Wallen’s arguments.

This has been a public service broadcast on how not to argue your case.

[Post edited slightly at 21:26 GMT 2009-03-31]

The Task-Oriented Revolution

12th January 2009

TheBlackCat posted this on an earlier post on this blog, and I thought it was worth sharing more prominently:

What I think will be a key revolution KDE will bring about is the task-oriented desktop. Plasma, Akonadi, Nepmuk, these are all parts of that. It will make computers smarter. Up until now computers did not care what you are doing, they cared about what you were using to do it. They organized themselves around what program you are using, not what you are doing with that program.

But people have different programs to accomplish the same task, and tasks often involve multiple programs. A computer that knows what you are doing and reorganizes itself to make that task easier is a huge leap forward in the way we work with computers. The Office 2007 ribbon interface is another example of that, but it is still embedded in the application-oriented desktop paradigm we have had up until now. It can even be taken a step further, allowing a computer to learn how you like to do certain tasks and organize itself appropriately. For instance such a computer could realize when you are chatting with your IT guy for a certain amount of time you generally pull up certain configuration programs, send him an email with an attachment, and check certain system monitoring applets. Let me get that all ready for your and stick them on a virtual desktop so you can get to it easily. KDE 4 provides the potential for a computer that automatically adapts itself to your work flow instead of you having to adapt yourself to its work flow. Imagine the benefit to businesses if you don’t have to train users to work with the system, the system will train itself to work with the users.

Everybody has different ways they like to do different things, but up until now the best they could do is try go set up their their desktop as best they can to make their most common tasks as easy as possible within the limits imposed by the system. Most people do not even bother to take advantage of the limited abilities their system provides, they simply use the default configuration. They never learn how they can modify and improve their computer experience, their efficiency, and their enjoyment. But a system that knows what users are trying to do, how they like to do it, and knows how take advantage of its own abilities to make those tasks easier would not need to rely on users spending the time and effort to learn the intricacies of the system, it would simply provide what they need when they need it.

Such a system requires four parts, I feel. First it needs a flexible and easily adaptable desktop. Plasma provides that. Second it needs something to track the relationships between data. Nepomuk and akondi provide that, or will soon. Third it needs programs that are able to understand how you perceive their relationship with the data and with each other. As I understand it is this is a major goal of KDE 4 over the long run.

Finally it needs to understand how you like to physically interact with the computer’s hardware. This, I feel, is still where KDE has serious limitations, and I think it is holding back the flexibility found in the rest of the desktop. The ability to configure the UI is amazing, but the ability to configure how the computer’s hardware interacts with and impacts the UI is very limited. Essentially we have keyboard shortcuts, that is it. Little else can be configured by the user.

The way we interact using the mouse is not flexible at all, we have three buttons and a scroll wheel. Modern mice generally have at least 5 buttons and a tilt wheel. The ability to dictate how the mouse interacts with the computer is pretty much limited to touching screen edges to activate a couple of effects, dragging windows across virtual desktops, and a few button presses on windows titles. Shortcuts involving mouse buttons are essentially unsupported. The ability to dictate how certain modes of interaction using the mouse effect the desktop environment is limited, in the relatively few cases where mouse interaction is configurable at all it has at most a couple of options.

Compiz has fairly extensive mouse interaction configuration, allowing pretty much any mouse button to be combined with a modifier key to control most aspects of the window manager. Windows 7 has some interesting ideas about moving windows, like the shaking windows to minimize others and dragging windows to screen edges to maximize them across half the screen. Of course certain people may not like these specific interactions, and in Windows 7 they do not appear very flexible, even compiz does not really support combining keyboard and mouse button presses beyond the use of modifier keys. But in KDE 4 the ability to dictate what effect a certain mouse interaction with a window or with a desktop will have is practically non-existent if you compare it to those examples, and is even more striking next to the extreme flexibility of the rest of the KDE 4 experience. So I think it important to be able to tell the system things like “shaking a window will have this effect”, “moving it to a screen edge will have this effect”, “tilting the scroll wheel left on the desktop will have this effect”, “meta+C+mouse button 5 on an applet will have this effect”.

This is even more limited when it comes to other types of devices. For instance there is no way at all to dictate what pushing a button on a joystick or a bluetooth device will do. They are simply not integrated into the KDE desktop interaction framework at all.

Another biggie that KDE, and Linux in general, essentially does not have at all is voice interaction. But I think this is an extremely natural way for people to interact, giving vocal commands is something people learn from a very early age. It is something that Microsoft has been working hard on supporting, and even most modern cell phones have it, but Linux in general and KDE in particular does not. Things like launching programs, switching desktops, and organizing windows seem particularly suited to voice commands since they are fairly simple and generally do not do anything terrible if there is a mistake.

The output side of hardware interaction is important as well. An example is having the computer know which printer you like to use when doing certain tasks (for instance a black and white office copier when printing PDFs, a color inkjet printer when printing photos). Or knowing that when you go into full screen when viewing a photo you want it to go full screen on your monitor, while if you set go into full screen mode with a video you want it to go full screen on your TV. Phonon and Solid seems to be trying to provide this to the Audio side of things, but it has applications for just about any output device.

Once you have the framework for being able to have a flexible method of interaction between input devices, output devices, programs, the desktop, and windows, it should become much easier for the computer to learn how you like to interact with it and adapt appropriately. For instance it could learn that when you are working with a text document and push the “play” button on your lirc remote you want amarok to open and start playing music, but if you stick a DVD in the drive and immediately after push the same button you want to open Dragon Player and play the DVD. It is extending the task-oriented desktop to the hardware side of things, to learn not only what you do and the process you use to do it but also what devices you use in that process and how you use them.


3rd December 2007

Given how my motivation went out the window when the interminable discussions about kdeprint happened (and it wasn’t even me or my work being attacked), I have great admiration for the people, like Aaron and the Oxygen team, who have carried on working despite being constantly attacked on the Planet and on the mailing lists for what is perceived as the sorry state of the desktop.

I can’t claim to have done huge amounts of work on Plasma, but I’ve done some and I keep up with what’s going on there, mainly.  On top of that, I’ve been running KDE 4 as my default session for a couple of weeks now, and I regularly rebuild everything.

I’m extremely impressed at the rate of improvement of the desktop.  Every time I svn up and recompile, some bug is fixed or some feature starts working correctly, or some new feature appears.  I’m becoming more and more comfortable with KDE 4 as my desktop.

Just in the last week, Jason Stubbs fixed the system tray.  Aaron posted that he’d fixed the Plasma crash on logout (I, meanwhile, couldn’t even figure out how to get a backtrace, since “killall plasma” doesn’t create the crash and logging out means Dr Konqi disappears before it loads the backtrace).  The Solid Device Notifier started working properly.

All these little improvements add up.  And the remaining major issues are being worked on as I write – in particular, the taskbar (which is functional, but not brilliant), panel placement and panel autohiding.

I can’t wait for the release!

PS: I also love the composite effects in KWin.  It’s really annoying that turning it on with my computer (ATI X300, free drivers) causes artifacts to appear that make using it really irritating.  When I get the chance, I’ll check with Compiz to see where the bug lies.