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.
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.
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.
The requirements of a login screen are the following:
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 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.
The plasma shell/corona etc doesn't provide us anything useful, and has more potential to go wrong
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.
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