Rationales

Why not just change KDM

I didn't like the configuration in KDM. it's way too complex, has lots of options that don't apply or do anything.

I also wanted to change the way themes work. I had to once change the background of a KDM theme for a very important client at my old job, whilst still looking like the standard SuSE login screen. The only way I could do this was to edit XML as root in front of a customer.

So I want to change the config, the front end and the backend needs replacing for Wayland. Once you start to replace every single part, it's time for a rewrite.

Also when I first started looking into this, I started on KDM code. Writing Qt Bindings for LightDM and using them was less work than trying to use the api from KDM. Look at the greeter code in both, mine is much simpler as it has to do a lot less.

Why is QLightDM in the same repository as LightDM (upstream)

QLightDM is the Qt bindings for LightDM, they are kept upstream so that they can be kept in sync with the GObject library and the backend. Qt bindings are automatically unit tested along with the GObject library, and the main LightDM maintainer has done an excellent job of keeping QLightDM up-to-date when he changes something.

Why are themes the way they are

I came to the conclusion there were two usages of modifying themes, and as such we want to:

KDM is currently a halfway situation of the two. Themes are too hard to modify for a normal user, just changing a background requires editing XML (or using the fallback ugly mode) and at the same time too restricted for anyone who wants to do something unique.

We've identified these as two completely seperate use cases and accomodate for them both (IMHO) correctly.

Why don't you use Plasma

We do.

The lines between plasma and QML with Plasma Components are becoming blurred, so I would argue that we do as we use the PlasmaComponents. We don't use Applets or Dataengines because they don't provide anything we actaully want.

We also allow themes to not use any PlasmaComponents in case they want to make something really off-the-wall crazy, which is something we have seen themers do if given the right tools.

Why don't use allow applets?

It doesn't match the use cases

The requirements of a login screen are the following:

Applets don't help add any of this. It's important to use tech to match the use-case, not choose a tech and try to think up requirements.

Very few of the existing applets are useful

At a login screen you almost always have no network, you have no access to the user's data. Without this the only applets that would work are: notes, bouncing ball, game of life and various clocks. This isn't enough to make it worth adding support.

Allowing dragging of applets would complicate the UI

Allowing the user to add a clock (for example) would almost always result in a login screen that just looked bad.

I would rather someone made a theme with a clock in a sensible, and shipped that as an alternative. It would result in a better user experience for people who want something, without widgets all scattered randomly (which would look crap) and without the risk of someone hiding/moving the very important login dialog.

Summary

The plasma shell/corona etc doesn't provide us anything useful, and has more potential to go wrong

You should show the users wallpaper like unity-greeter does

Plasma is very complex in this regard. The wallpaper may or may not be an image. You have one wallpaper per containment, you don't know which one is the main containment, and on top of that one per activity...and you don't know which one of them is going to be loaded first either.

Best I can do is make it super easy to change backgrounds in LightDM so that they match. Which is what I've done.

Why don't we use that KDE API for checking passwords

KGreeterPlugin?

Password handling is done by LightDM, doing it ourselves wouldn't really make sense. The stuff KDM/screensaver uses whilst arguably is slightly better than what we have still isn't very good. There's no GUI way to configure which PAM modules are required anyway, so it's all rubbish (atm).

Robert (the LightDM guy) has some exciting plans for some updates to PAM which acts as an abstraction layer and makes the password input less crap and more flexible for everyone writing GUI layers on top. Including support for allowing setting which auth mechanisms are required from a config

Long term, I will introduce something similar based on the above

What about the design of LightDM

See here.