Thursday, 12 November 2009

KDE4 multimedia in Slackware

Multimedia has always been a bit of a pain in Linux distros. It's riddled with patents and other restrictions, which free-software purists dislike. So even simple things like playing mp3 files often produce a lot of hassle. KDE3 had its own sound server, called arts, which in recent years has been unmaintained and generally unsatisfactory. KDE4 replaced this with a new multimedia framework called Phonon. This can work with different backends, of which the usual ones are gstreamer and xine.

In both Debian and Slackware, gstreamer is the default. When using xine in kde3, I used the Windows codecs from mplayer, but gstreamer uses its own plugins, of which there are several packages: gst-plugins-base includes quality open-source codecs like ogg and theora, gst-plugins-good adds others, including containers like flv and avi. The mpg codecs are in gst-plugins-ugly, i.e. those which are good-quality but have license/patent issues. Debian includes all these plugins somewhere in its repos, but Slack only has base and good, so you cannot use mp3 files with gstreamer in the standard Slack distro. Fortunately, ugly is available on which also includes the various libraries needed which are also not in standard Slack. Install all those and you can then listen to mp3 files in KDE programs like Juk.

Mind you, Slack does include mpg321 which enables you to play mp3 files on the command line, so you could set up a file association in kde to use mpg321 to play mp3 files.

Another of those areas where Linux distros create a lot of hassle for something that should be simple.

Back to Slack

In a previous post, I said that I was using Debian on my EEE. I have though become increasingly frustrated at the length of time it takes Debian to move programs from sid to testing. When I first installed Debian, I used the default option, which is stable (i.e. Lenny at the moment) with Gnome desktop. That was, however, not really what I wanted, so I went off and RTFM, and found that you can change this by using expert mode. So, I kept Lenny on his own partition, and installed KDE on another partition. I first tried with sid, but couldn't get X to load - gave me strange error msgs which I didn't have time to try and fathom - so I installed testing instead. In theory, programs are quickly moved from sid to testing unless there are major issues, but the new versions of KDE seem to have got stuck in sid. In the meantime, KDE have released 4.3.3, but Debian have still not moved 4.3.2 to testing, let alone 4.3.3. As Slackware made 4.3.3 available in current just a couple of days after the KDE folk released it, I decided to go back to using Slackware. In fact, I kept testing, and installed Slack on top of the Lenny partition, as I wasn't really using this for anything.

In principle, the big advantage of Debian is the vast package repos, which Slack doesn't have. However, there is now an excellent collection of additional Slackware packages at I've so far found only 2 packages I use that are in Debian and not available for Slack: mapserver, and Google Gadgets for Linux, which can be used as KDE plasmoids. I could compile for Slack, but, if necessary, can also boot my testing partition and use that. There are a couple of curious little bugs in Slack I've not got to the bottom of yet: those icons that are in Hicolor but not in Oxygen are not displayed; and Ark seems unable to open tar.gz files (I think this is because a compile option was missing).

Thursday, 5 November 2009

Zoho remote api

In a previous blog on strategies for replacing the desktop, I wrote: "In theory, there is another alternative - data local, software on the web - but I never heard of anyone implementing that!"

Turns out that's Remote API does precisely that. This enables you to keep all your data on your own server but use Zoho's editing program to change them. Piotr Malinski has example code to do that with Curl in Django or PHP

Monday, 2 November 2009


I've just been looking at Mark Pilgrim's interesting pages on HTML5, especially his browser tests for various new features. Here's the results for the various browsers that I use on my KDE setup.

Edit: 14.11: I have now updated this to show Slackware Firefox as well as Debian's Iceweasel which appears to be far less capable. I've also included Arora (not surprisingly as they both use QtWebKit, this is the same as KDE plasmoid).

Konqueror (KHTML)Plasmoid/Arora (QtWebKit)Firefox (Gecko)Iceweasel (Gecko)Chrome (WebKit)
Canvas textnyyny
Videonny (Ogg Theora)ny (Ogg Theora and H.264)
Web workersnnyny
Offline appsnyyyy
Input typessearch, rangesearch, tel, url, email, number, range, color
Placeholder textnynny
Form autofocusnynny

Clearly, Konqueror is worst. After only testing Iceweasel I thought Gecko wasn't much better, but Firefox is far superior at these tests, so it looks like this is browser dependent, not browser engine. Firefox even manages geolocation, though I tested this via my ADSL link which is pretty useless as it gives the ISP's location not mine. The WebKit browsers also score well at these tests.

Centralising bookmarks

It's always the way that no sooner do you post something than you discover additional information. Since writing my previous post, I've discovered two attempts to provide exactly the kind of centralised bookmarks and password managers I've been looking for.

The first is Xmarks which provides exactly this kind of service, albeit only for Firefox (though Chrome is promised). This can sync both bookmarks and passwords. Although it's run by a private company and by default stores the data on their server, you're not tied to it - you can use your own WebDAV or ftp server to store the data, and you can export the stored bookmarks at any time. An additional nice feature is the ability to create 'sync profiles' , which enable you to limit certain bookmark folders to a particular computer.

Meanwhile, Google recently introduced their sync facility, though frustratingly this does not seem to be available on the Linux version as yet. This stores the bookmarks in with the Google account, though it seems they plan to open-source all this, so presumably could be done elsewhere too. It will also use the standard XMPP for syncing.

Now all that's needed is to persuade KDE to use this instead of the built-in bookmarks.