KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   

- News . 
click to vote up

logging into Plasma Workspaces 2

Published Mar 15 2013 via RSS

You're probably wondering what I was doing at 1am last night. I get asked that all the time. Well, mostly by people I live with, now that I think about it. "What were you doing on your computer at one in the morning?" they ask. The answer is usually quite exciting. Take last night, for instance: I was having a meeting with people to discuss display managers. Yes, the wonderful world of login screens.

We now have a truly amazing spreadsheet that tabulates the current state of three display managers. It has sections from community, "soft" attributes (such as licensing and build system), technology support, features and performance. Unfortunately, this did not lead us to any firm conclusions but it was very useful in helping better understand the landscape here, which is what we were after.

Our Requirements

The question we are trying to answer is this: What display manager will we use in Plasma Workspaces 2? Candidates must match a simple and clear set of needs:
  • Must be lightweight. We want to use this on desktops and devices.
  • Must be maintainable. (Self explanatory.)
  • Must be able to write the user interface in QML.
  • Must be able to be a Wayland system compositor.
How hard can that be, right? ;) Bonus points are awarded for things like:
  • Used by other projects (co-investment and user consistency)
  • Familiar tooling (we can always learn and use another revision control system, but we'd rather not as that raises the bar for participation)
Given that as a starting point we looked at three options and here's what my take-away on each was.

Contestant #1: KDM

This contestant is a deep soul with much complexity who likes things the old-fashioned way. 20 year old scotch is its drink of choice, and it hates walks on the beach (not much of a romantic, you see). It holds advanced degrees in many traditional practices. Let's say hello to .. KDM!


KDM does a lot of things very well. It is highly scalable (10k users in LDAP? No problem.), supports features such as remote log in, can be used with hardware and biometric keys and much more. It is themable, as a Google images search can quickly confirm. 

Unfortunately, there has not been much work on it lately and none of the active developers know the codebase very well. And what a codebase it is! 34,000+ lines of code, nearly 14,000 lines of which are C with the rest mostly C++. It is a beast. Interestingly, the KDM settings UI is 6,400+ lines of C++. That makes it's control panel nearly twice as big in terms of code count as the Plasma Active shell.

Work had been started on making a QML front end for it (twice, I believe) but it never came to full fruition, and it is unclear just how best to add a Wayland system comositor to KDM would be. So though it has served us well, KDM actually fails to meet our requirements.

Contestant #2: LightDM

This contestant is a young but accomplished fellow with lots of modern features. An outgoing sort, he strives to be useful to all around him and tries not to make many assumptions about what would make you happy. With lots of friends, he's seen at the entrance to many parties .. say hello to: LightDM!


With just over 20,000 lines of C code (though getting closer to 22,000 with the KDE integration bits), LightDM has a terrific number of features. It has a clear separation between the toolkit-agnostic backend and user interface providing front-ends that communicate via a local socket to get the deed done.

Guest login, auto-login, VNC/RDP/XDMCP, power management, fast user switching .. it's all there. Outside of a few things like biometrics, it has a superset of KDM's features. It also has support for new Linux middleware such as systemd and AccountsService, and does it all with a very small footprint (the daemon takes well under 1MB of RAM). It is also quite extensible and used by a large number of projects including the *buntu family of Linux distributions, RazorQt, Elementary and XBMC. 

There are three main contributors to the core LightDM according to the commit logs, all of whome work at Canonical. In addition to their efforts, David Edmundson's has been working on KDE integration for LightDM in KDE's repositories. Thanks to his work, you can write your UI in QML and PowerDevil is used for power management giving us consistency and portability. There is still work to be done, but it works rather well right now. I've been using it on my laptop for a while now, so that's not just theory.

A big piece of work that needs to be done is to add a Wayland system compositor. This is where things get tricky. LightDM is a Canonical project, and as such they will not be working on a Wayland compositor since they decided to part ways with the rest of the Free software ecosystem and create their own display system, Mir. One of our big questions was whether a Wayland compositor would be welcome.

Robert Ancell, the LightDM maintainer, attended last night's meeting which was extremely helpful. According to him, a Wayland backend would be welcome (though they won't write any of it) and there will be no hard dependencies on Mir in LightDM. This is reassuring, but means we need to trust the roadmap of Canonical a bit here and also means we'll be doing all the heavy lifting on the Wayland side. David has stepped up to do that work, however, which is also encouraging.

Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. This means that we won't really be able to contribute to core LightDM very effectively as a team. Some individuals may choose to do so, but several have already stated they won't, including those with the most experience with things like Wayland.

The fact that it is already widely used is a plus, however, as it means we may be able to share some efforts with others. This is particularly useful for system integration bits. For instance, Robert noted that Ubuntu will be working on logind support for LightDM. That said, some of our downstream distribution partners seem less than keen on supporting LightDM in their distributions.

So in summary: very featureful, relatively mature after three years of development, we already have a good amount of integration, but it carries risk due to community and commercial dynamics.

Contestent #3: SDDM

This young whipper-snapper is still wet behind the ears, as they say, and is still learning the ropes but she's fast and lean and sports a shiny approach to life. Let's say hello to SDDM!


This project is only three months old and as such is, by far, the youngest of the bunch. It also has the fewest features. However, with less than 2,200 lines of code it already provides the daemon/frontend duality with socket communication much as LightDM does and the user interface is written with QML. In fact, the entire thing is written in C++ using Qt and the code is very clean at this point. As with LightDM, it's memory footprint is more than reasonable.

It is an open, community developed project and has been picked up by the relatively new QML-based Maui desktop project. The use of C++, Qt, CMake and git make this a very familiar feeling to the code base for us Plasma hackers. The QML package structure is actually very similar to our own, and I understand that was not completely by coincidence. There is one main developer with two others who have made some contributions as well. This is fairly similar to the LightDM development profile, except that the contributors are not paid by the same companies to work on it.

As with LightDM and KDM, a Wayland compositor needs to be written for SDDM. It also needs to gain support for a large number of features it is currently missing, such as AccountsServices, guest accounts and a number of others. It does already support systemd and have some power management features. 

The biggest concern I have is the youth of the project. Will it continue to be worked on and mantained? Will other projects also adopt it as it matures? Only time can tell.  I am very keen to seen how SDDM develops over the next couple of months.


This is a difficult decision to make. KDM is not going to make the transition into a QML and Wayland world with us, despite it having served us well in the past. We need something to take its place, and we'd prefer not to start from scratch when there are good choices that already exist.

On the one hand we have the feature filled LightDM with three years of track record behind it, but which still needs work to make it do what we want, and which has a relatively large codebase that will be hard to contribute to. That said, David has already put a good amount of effort into the QML support for LightDM.

On the other hand we have a youthful, and thus largely unproven, SDDM which needs even more work than what we'd have to dedicate to LightDM but whose code base is very small, modern and uses familiar tools and which is developed openly. We won't need to do any QML work, but we will need more system integration features. With SDDM, there'd also be very limited (if any) opportunities to work with non-Qt/QML desktop projects.

If more projects interested in Wayland got involved with either LightDM or SDDM, that could tilt the scales as we would be able to share the compositor work with them. Personally, I'm torn between the open community and great code base of SDDM and the utility, maturity and wide usage of LightDM.

BackRead original postSend to a friend

Add comment

Add comment
Show all posts

 Who we are
More about us
Frequently Asked Questions
Updates on identi.ca
Updates on Twitter
Content RSS   
Events RSS   

Add App
Public API
About GTK-Apps.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Sponsor us
Report Abuse

Copyright 2007-2016 GTK-Apps.org Team  
All rights reserved. GTK-Apps.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.