KDM plans and lightDM

Harald Sitter sitter at kde.org
Wed Jun 15 00:14:36 BST 2011

On Tuesday 14 June 2011 15:37:25 Shaun Reich wrote:
> On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter <sitter at kde.org> wrote:
> > Should that ever get finished. Shaun?
> Good question ;-)
> Yeah, it's in a pretty finished state, after my unintentional hiatus.
> Mostly I've been cleaning stuff up(and yes, I've been actively
> committing lately), so that the qml code can look the best. It already
> runs plasma and qml and logs in, just have a few more things to do on
> it. (kinda refactoring a bit so it doesn't come to bite me later on,
> at the moment..)


> > In particular it is my personal believe that a strong separation between
> > DM logic and desktop binding/integration magic is beneficial from a
> > structural POV. That way you can easily swap the integration bits
> > (QWidgets -> Plasma QGV stuff -> Plasma QML stuff?) around without
> > having to poke into the DM stuff at all.
> Well, you see. You have to understand my frustration --> the thing is,
> this *already* exists in KDM. And anything that is deemed
> unsatisfactory(not everything's perfect, naturally) could easily be
> changed of course.

I very much understand your frustation. But also as downstream developer (and 
I count Alex in there too as he is very much aware of the advantages of a 
downstream POV) I get a lot of input with regards to what is not in the 
condition it should be to compete with other pre-login experiences. Be it from 
friends or people at fairs, whenever KDM comes up there are some major 
annoyances (though to put this into perspective: KDM does not come up as topic 
that often, which IMHO is still a bad thing as I'd rather have people go "uhh, 
your login thing is so awesome...").

So, to direct attention to the subject. I think the general scheme was to find 
out where to go with KDM and whether LightDM would be an option if all else 
fails. Find out how to make KDM rock the user's experience is primary 
objective, at least for me.

> Everybody talks about it like it's some magical unicorn that hasn't
> been spotted before, but the truth is, it's staring everyone in the
> face.
> In fact, I have dealt directly with this separation when I've been
> working on the Plasma frontend, and based some of it around the
> original kfrontend (qwidget) code. So I don't see what the big deal
> is, considering I've already worked with this myself...

My argument was more in the general direction of moving things that we should 
not be heavily involved with elsewhere, and I believe that the larger DM logic 
is such an area. By outsourcing (what a nice word) this part in technology 
that is used by more than one party we get more exposure to actual production 
systems, thus more testing and in the end better quality in the long term (not 
that anything was wrong with the quality of KDM, just saying).
Now, I reckon that XDM could, or perhaps should, have been exaclty that, 
though it did not quite work out.
It still seems like a nice enough idea to share generally sharable things.

To me, as someone who is not terribly knowledgeable in the area of display 
managers, it just seems like a waste of resource to have stuff implemented in 
not all that different ways on different ends (GDM and KDM). Though since there 
is no plan to have GDM replaced by LightDM on sytems other than Ubuntu this is 
all a bit moot. Even though I think sharing with part of the ecosystem is 
still better than no sharing at all.


More information about the kde-core-devel mailing list