KDE and LightDM

I'd like to share below details on a project I've been working on before I try pushing on the KDE mailing lists and seeing if there's any interest.

What is LightDM?

LightDM is a cross-desktop display manager (think KDM). It's designed to be fast and lightweight, it is written to replace GDM Gnome's display manager.

What makes LightDM interesting for KDE is it is designed to to have multiple 'greeters'. This is the front end that sits on top of the daemon and does the displaying to the user asking them for login details. This means we can have our own KDE interfaces, whilst the Gnome people do their different UIs all whilst sharing the same daemon that handles all the hard parts.

By having this this multiple greeter system, we don't need have to have just one KDE greeter. It becomes very easy to experiment with new ideas too. There was talk about a plasma interface to KDM which I don't think ever got anywhere. With LightDM and my QLightDM library writing a plasma greeter would only take a few evenings at most. (I remain convinced that using plasma here is a good idea, but I fully support anyone wanting to try.)

Each greeter could also be themeable, so this is a bit like KSplash; we have the normal KSplash engine with a big collection of themes, but we're in time also adding KSplashQML which is an engine to allow a different set of themes on a different technology.

What's wrong with KDM?

Nothing in particular. I'm not trying to oust that project or say anything bad about it (except I can't stand the KCM. There are far too many options that don't do anything if you're using a theme. Greeters help solve this.). I simply think this a cool project, which I'm getting involved in.

By using a cross-desktop project we get to share working on the daemon backend, so we will have wayland support at the same time Gnome does. I'm a massive fan of freedesktop projects and not duplicating work! It's much better to try and get involved from the start, so we can shape it where we want it to go.

What's been done?

I got interested in the project after seeing a post on Planet Ubuntu and thought "KDE could use some of this.". I've written a Qt library for making greeter engines, as well as a very basic demo greeter which is more for testing than a real demo of what can be done. This library is designed to be very QML-ready, with a strong emphasis on using models rather than simple lists.

This is all stored within the main lightdm source code repository.. There is also a PPA available if Kubuntu users want to try it out themselves.

I've got an idea in my head for the direction I want to take it with QML themes that will be hopefully lead to the same broad range of designs that KDM has, but more flexible whilst keeping a really sensible config dialog.

Alex Fiestas has been working on some changes in KDE4.7 to make sure suspend, shutdown and user switching work still work whilst using lightDM. Making it a fully replaceable manager.

Obligatory screenshot

If you'd understood the above you'll realise this is all about the backend library, and having a flexible structure, however I can't leave a blogpost without putting in a screenshot.

Planning the first release of KDE Telepathy

Given the various blog posts, and (somewhat unnecessary) hysteria over the news of Skype I felt like I should give an update on what's going on in KDE Telepathy.

Pace over the past 5 months has been ace, we've got a lot done, and as mentioned by a few people already - we're releasing "soon"! We don't have a fixed date, but instead we will release when a set list of outstanding bugs are fixed. Probably about 4 weeks time. (unless I die of stress organising it all in the meantime)

What's in this release?

There's not as much as we'd like, but we're making a concious effort to ship something that really works. You should be able to create any type of IM account and have basic contact-list tasks and have normal text chats.

At this stage nothing is really fixed, and we're in early stages of shaping where we're going. Hopefully you'll see what we're aiming for with KDE Telepathy and a start to the realisation of some of what telepathy is about.

This first release won't have all the nepomuk integration blogged about by George Goldberg, nor will it have audio/video chat. Rest assured that there are a lot of cool designs, ideas and even code floating around and that this will come, but only when it's ready.

There's still plenty of opportunity to get involved, we've got some junior jobs left that need doing. Testers are great, providing they're really willing to read a lot documentation and really get stuck in, there's quite a bit of effort needed in getting a working setup at present.

What else is coming?

We have a GSOC student that I'm mentoring over the summer to really nail bringing instant messaging into the core of the Plasma Workspace. I won't spoil the details as he'll be blogging soon, only to say it's an exciting time to be in KDE.

KDbg for KDE 4 Rc1

Before getting fully caught up in KDE Telepathy I helped out working on an interesting project Kdbg, a graphical front end to the debugger.

Whilst several IDEs have this built-in, a standalone program allows for more detailed data inspection, and is a useful tool when debugging code not set up in your IDE.

Version 2.4.95 is the release candidate of the first KDE 4 release, and I felt it deserved advertising on PlanetKDE.

Below is the mailing list announcement from the lead developer Johannes Sixt:

I've pushed out KDbg 2.4.95 to the git repositories at sourceforge and


(branch master).

KDbg is now ported to KDE4 and has also recived a slight face lift with new
button art work. The program icon should be exchanged, but I'm not an

Please report your impressions so that I can make the final release next week.

To compile the program after you checked it out:

1. create a build directory next to the source directory
2. cmake ../kdbg
3. use cmake-gui to check for a suitable CMAKE_INSTALL_PREFIX
4. make
5. (possibly as root) make install

Special thanks go to David Edmundson and Gilles Allard for their valuable help
in porting to KDE4.

What’s happening in KDE Telepathy

Since my last post things really have started to kick off; The account configuration module is looking a lot tidier and the process of creating per-protocol user interface is greatly simplified. A big thanks to the KDE Usability guys for taking the time to respond to my email.

We had an IRC meeting last Monday where we discussed what was left to be done, and assign tasks and maintainers for the various components.

We now have some-one starting writing a contact list, and we're making lists of outstanding tasks in the other areas, things are starting to shape up nicely.

As it's a blog post, most of you are just here for the obligatory screenshots:

If you saw the same ugly shots from last post, you'll see this is definitely progressing nicely.


Will KDE Telepathy support <any protocol here> ?

This is the question I'm asked a lot, and the answer is always the same. "If Telpepathy supports it, then we'll make damn sure KDE has code to support it. If Telepathy doesn't, then there's no point asking us". An incredibly outdated wiki page listing the state is available here: http://telepathy.freedesktop.org/wiki/Protocols%20Support. Google is sometimes a more useful in this regard.

Can I help?

I'm busy writing up some instructions on getting started with a setup. Once that's done (hopefully the end of the week) I'll post to PlanetKDE again. Hold tight!

KDE Telepathy Hack Day

Just a reminder that today is a "get helping KDE Telepathy" hacking day.

I'll be in our IRC channel #kde-telepathy all day to help people get started on working on our accounts manager.

If you're interested in helping out with instant messaging and collaboration on KDE now would be a great time to get involved. Anyone with basic C++ skills will be able to help.

A list of the tasks we want to get done is here: http://community.kde.org/index.php?title=Real-Time_Communication_and_Collaboration/Components/Accounts_KCM_Tasks

Along with some further information about getting started here:

Telepathy Help Hacking Day – Saturday 8th Jan

KDE Telepathy has quite a lot of work left to do, so I'm running a day to get more people involved and help hacking. I intend to focus purely on the System Settings module where people set up their IM accounts.

The interface needs a lot of UI attention and tidying up so we need people of all skills and interests.

Each protocol (MSN/Yahoo/etc) needs it's own user interface, this is a fairly straightforward task, but there are a lot of protocols Telepathy supports!

On Saturday join us in #kde-telepathy on freenode we'll help make sure you're set up with the current source, and you can get hacking! Hopefully we can get the entire system settings module nearly finished by the end of the weekend.

Below are some screenshots of the current state (which aren't much to look at) hopefully this time next week I'll be posting something much nicer.



Autostart in KDE Linux

The Autostart folders in KDE/Linux

When you first log into your KDE session a large amount of application/system tray programs are automatically started. It can be quite hard to work out who is starting what, and in particular to make changes.

Applications are started by a .desktop file in one of the autostart directories.

The following folders are all checked for .desktop files:

  • ~/.kde/Autostart
  • ~/.kde/share/autostart
  • ~/.config/autostart
  • ~/.local/share/autostart
  • /etc/xdg/autostart
  • /usr/share/autostart

I don't really know why we have so many.

Anything inside the /usr/ or /etc folder will have been installed by your distribution.

Disabling Autostart Files Provided By Your Distribution

KDE provides a wonderful tool in systemsettings ("Startup and Shutdown" -> "Autostart") for managing your personal autostart services (in either of the .kde directories) however it doesn't cover systemwide autostart scripts provided by your distribution packages, or created by the gnome apps.

Sometimes however it can be useful to override your distribution autostart preferences, for example I don't like having the printer-applet running as I don't own a printer, but it seems a shame to uninstall it in case I need it.

The Wrong Way to Disable Application Autostart

Contrary to what most people actually do, the correct way to disable service is not to delete the files your package manager has installed. There are a few reasons for this:

  • It will affect all users on the system
  • It's an abuse of your root access (which you may not have)
  • As soon as the package upgrades, the file will be restored and it will come back to autostarting again - which isn't what you want

The Right Way

The correct way to disable a package installed is actually to copy it to your personal autostart folder. Anything of the same name in ~/.kde/share/autostart overrides the .desktop file in the default installations. Once we have copied the .desktop file we can make changes.
Add the following line to the .desktop file you have just copied:


A personal opinion

I think everyone would agree we could do with normalising how many autostart folders we have, which would be easier to do by us losing our kde specific ones and following freedesktop standards.

I also wonder if disabling systemwide autostart services in the manner listed above could be handled, it seems do-able to me. If someone comments approving it, I'd try and see if I can make a patch.

I'd also like it if developers really think hard about whether something actually needs to have a system tray icon constantly loaded on startup or whether it can be an easy to find seperate application for a user to run. It provides less visual clutter as well as a faster initial load time.


The Freedesktop Autostart Spec - note this doesn't actually cover the real state on a Linux box, only what it should be doing.

Configuring KDE paths

As someone who posts to kde-apps.org repeatedly one of the biggest cause of problems I encounter is users missing out the flag '-DCMAKE_INSTALL_PREFIX=/usr' when running cmake.

The current situation is somewhat ridiculous, applications default to installing into /usr/local, which is in the user's application path but not in the KDE path. The result of this is an application that can load (because it's in the executable path) but not be able to find any of it's resources.

You can check your kde path by running:

kde4-config --path data

The best solution to this is to add '/usr/local' to KDE's path, this allows you to install KDE apps separately from where your package manager installs applications and save you having to worry about compile options.

To do this, set your /etc/kde4rc file to the following:


KWakeOnLan 0.2

Today I got a patch for a piece of software I released almost a year back and had totally forgotten about

The patch adds support for setting the broadcast address in KWakeOnLan so that it is possible to make it work over a VPN or potentially any internet connection.

It's the first time I've had someone submit a patch for a piece of software that I'd written exclusively till that point, and it feels really good - it shows people are using your software enough to want to edit it

So thanks to Sebastian Kloska I present KWakeOnLan 0.2 + (a few interface tweaks by me)

Proposed new KDE toolbar configuration

The current tool bar system in KDE is a bit dated, the window is filled with lots of buttons, and reordering items isn't all that intuitive. It's not all that 'user friendly'.

The existing toolbar configuration

My suggestion

I've made a working prototype of a new click and drag solution. Essentially it's a very similar toolbar configuration scheme to that of Firefox. A lot of the code required already existed in KToolBar, it just wasn't being used. This demo only really has changed to the toolbar editing dialog. If this is accepted by kde-usability people, I'll try tidying it all up, ready to be a patch to show to the kdelibs guys.

Below is a screencast showing my prototype mockup:

Ogg vorbis video

Source code