On Wed, May 18, 2011 at 1:06 AM, David Edmundson
> I stumbled upon your blueprint plans for use of LightDM in Kubuntu 11.10,
> and as the person who has written most of LightDM-qt so far I wanted to add
> some opinions and an update on where the lib is.
> Firstly if you're going to discuss LightMD, it would have been nice to have
> been notified.
We did not even know you were working on it (well, at least I did not
). The plan itself is to carry the whole discussion and
implementation upstream to KDE, and see if KDM is a lost cause and if
it is whether people are in favor of going with LightDM. At least then
you would have known of the discussion I assume. At any rate not
inviting you to the UDS discussion was by no means intentional.
> There's so much I intend to get done with it,*but I've been really busy
> trying to get KDE Telepathy out. It's all already consuming far more time
> than I really should let it.
> Anyway. What's the current state and what needs to be done:
> Robert Ancell (the main LightDM guy) has been refactoring the backend, which
> has led to some changes in the Qt lib which I'm not 100% happy with. Instead
> of just jumping on dbus, we now have a lot of GTK lib copying+pasting with a
> thin Qt wrapper in the main class of the greeter. At a minimum I want this
> moved out to a*separate private*class to give a very clean maintainable
> header to the*publicly*exposed main lib. Ideally we'd want someone like
> George Kiagiadis involved who is extremely pro at auto-building Qt bindings
> for GTK and get a library that isn't going to fall apart as soon as the GTK
> version updates.
Selling a GTK+ dependency to people will be *very* difficult, so I
think DBus is the better choice really.
> I have a far better demo greeter on kde's git repo than the one in bzr repo.
> I'll try and merge that.
> I want to give it a really significant refactor that switches the lists of
> LdmSessions, LdmUsers, and Langauges to be Qt models. *I also want to expose
> the power management parts as Q_PROPERTIES.**I did start this a while ago,
> it's not finished but if I worked on it, I could get it done.*This not only
> makes GUI's quite a bit quicker to build, but will make plasma bindings very
Also necessary for QML, so definitely worth the effort.
> It was started by me a year ago, and I wasn't as familiar with KDE
> standards/lib consistency as I am now. It's not bad, but it's far from
> perfect.*I would really appreciate it if you could give me a month to
> completely tidy up all the crap up to make it decent ABI stable code.
> As for plasma:
> With my LibLightDm-Qt hat on, I will absolutely support everything you do
> and will do anything I can to make the library really easy for you to use,
> let me know and I'll do what I can to update the lib.
> With my generic developer hat on, using plasma is an ill-thought through
> idea. To me it seems you've jumped to the solution before you've worked out
> what problems you're trying to solve are. I also believe it's a security
> risk, will lead to slow load times and potentially unstable login screens. I
> think it will lead to a lot of future problems. I have an alternate (pure
> QML-oriented) scheme in mind that allows for
> greater*flexibility/theming*with a sensible KCM that I think is pretty
> solid. However I'm not one for arguments, and LightDM does allow for
> multiple greeters (both built off the same greeter lib) really easily so we
> can easily do our own thing.
There were no particular decision set in stone about using Plasma.
Just seemed like an obvious choice. I must say having a QML greeter is
certainly intriguing too, especially since I understand Canonical
wants to invest in a Qt greeter anyway, so we could share resources
BTW, you can listen to the session at 
kubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel