Posts Tagged ‘KDE’

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.

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://anongit.kde.org/scratch/alexmerry/kscreenlockmgr
mkdir kscreenlockmgr.build
cd kscreenlockmgr.build
cmake ../kscreenlockmgr -DCMAKE_INSTALL_PREFIX=$(kde4-config --prefix)
make
sudo make install

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

Harassment at FOSS Conferences

10th December 2010

I recommend you go and read Valerie Aurora’s article on harassment at FOSS conferences on LWN.net.  It’s grim stuff, but also a positive piece – looking at how to improve things.

I’d like to think that this sort of thing doesn’t happen at KDE events, but I guess everyone like to think well of their own community.  And I don’t mean that I’d like to think no harassment happens at an event as large as Akademy, say – I’m not that naïve.  But I would like to think that KDE’s atmosphere is one that welcomes everyone, not just men, and doesn’t tolerate such behaviour.

Is this really the case, though?  I don’t think that I’m in a position to answer that, being a man and not having attended many KDE events.  It’s not something I’ve ever experienced or come across, but there’s no reason I should have.  The antipathetic response to Stallman’s “EMACS virgins” quip at GCDS 2009 didn’t really inspire me with confidence on this front, however.  There was outrage, sure, but it certainly wasn’t universal.

What is clear is that the wider software industry and community has issues attracting and retaining women.  While this is a larger problem that we can’t solve on our own, what we can do is make sure that everyone is welcome in our FOSS communities, providing they are willing to get involved, and that we don’t make anyone feel uncomfortable.

So I’m asking some questions: what do we need to do to make this a reality, at least within KDE?  How far away from this are we?  Where do we need to focus our efforts?  I’d be especially interested in hearing from women in KDE on this, as you will have first hand experience of the issues.

What Brave New World Is This?

16th November 2010

As most of you are probably aware, HAL is dead.  So let us all cry out: HAL is dead, long live… what, exactly?

If you’re wondering what on earth HAL is, it is (or was) a daemon that sat on your computer and told interested parties (such as KDE applications, via Solid) about various bits of the hardware.  This went beyond abstracting away kernel interfaces, however, and included information about laptop batteries that have been recalled, for example.

However, it was decided that HAL was getting too big for its boots and was failing to acheive its stated goal of “making hardware just work”.  But it was filling a need.  So what is sweeping into the void to replace it?

Well, there’s UPower, for all your power management needs.  It replaces those parts of HAL that dealt with screen brightness, the power button, the lid closing and entering various power-saving modes.  It even goes further than HAL ever did, allowing applications to request latency targets, for example.

Then there’s UDisks.  You may be thoroughly unsurprised to learn that it deals with the various bits of storage you may at various times attach to your computer: anything that appears as a block device, basically.

For many other services, you are expected to deal with either higher-level services like NetworkManager (or WICD, or other solutions) or with lower-level ones like PulseAudio or ALSA.  And for everything else, there’s direct interaction with udev, via libudev.

This is all very well, but what about all that extra information that HAL provided?  Well, UDev provides a device database that allows extra information to be stored with devices.  UPower provides battery recall information using this mechanism, for example.  There is a media-player-info project that provides UDev rules and some desktop files that furnishes interested applications with information about supported protocols and media formats of various portable media players.

But after that, I get stuck.  I guess that many of the video power management quirks that HAL documented are expected to be dealt with by the kernel.  But this is just an educated guess.

The major problem with this “kill off HAL” project is the sheer lack of documentation.  UPower has a useful website.  UDisks has an almost entirely unhelpful one.  media-player-info doesn’t even have a website, and you wouldn’t really know to go looking for one anyway unless you follow the right development mailing lists.

Solid is currently having problems with developing replacement backends for HAL.  What is the correct way to get the processor information that HAL previously exported?  LibMTP used to augment HAL’s media player information store with its own information, but there is no clear way for it to extend the information provided by media-player-info.  How should libMTP provide that information now?

All this should really be documented somewhere.  Maybe it is, and I just can’t find it, but that means it’s not documented in a sensible place.  The sensible places being the HAL website and the DeviceKit website (DeviceKit being the overarching term for the “stuff to replace HAL” – UPower and UDisks in particular).

I really hope someone knows what’s going on, and I wish they would communicate it to the rest of us.

EDIT: I realised that, freedesktop.org being largely composed of wikis, I could do some improvements myself.  The udisks site now has some useful information on it, and there is a media-player-info site.

Akuadec

9th July 2009

Another day of the Gran Canaria Desktop Summit. After yesterday’s post, I got several offers of power adaptors. However, I ended up buying one on my way back to the hotel, along with a bunch of food for lunch today (the lunches here at the university are poor and quite expensive for what they are).

In fact, speaking of food, I had the worst meal I’ve had this week, and one of the worst I’ve had in my life, last night. We went to a Chinese all-you-can-eat buffet. Now, now, don’t scoff. I’m had some good (although never excellent) food at all-you-can-eat buffets. It seems that the Canary Islands is not the place for them, though. This one was so bad that after my first plateful, I was still hungry but didn’t want to eat any more. Avoid like the plague.

This was in direct contrast to the meal I had with the Amarok guys the night before, which was really nice (if expensive) – masses of paella, salad, chips and warm chocolate brownie. It was seriously good.

Today we had more Amarok discussions. So far we’ve discussed:

  • liblastfm on Windows
  • Playlist synchronisation
  • Unit testing
  • Whether scripts should be able to respond to Amarok quitting (and potentially slow it down)
  • A UPnP collection
  • Reorganising the source files
  • Playdar
  • The UI for dynamic playlists, and context-sensitive information for the area on the left of Amarok (where collections and services etc. are)
  • The EngineController class
  • Mac/Windows ports

Still to come:

  • Media devices update
  • The evil “organise files” bug (pro tip: don’t use Amarok 2 to organise your files for now)
  • UI clutter

We’ve had a very productive couple of days, and Leo’s been taking photos of the whiteboard, so we have a permanent record of our discussions.  Expect blog posts about the cooler things we discussed.

Guademy

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.

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]

Twice as Good

11th December 2008

I’ve decided to go 64-bit, to make full use of the 4Gb of RAM I recently bought. So I have no KDE until it’s finished compiling again.

*idly wonders if he’ll have the same bugs in trunk when it’s done*


Follow

Get every new post delivered to your Inbox.