LightDM-KDE

Harald Sitter sitter.harald at gmail.com
Tue May 17 23:26:41 UTC 2011


Hi David,

On Wed, May 18, 2011 at 1:06 AM, David Edmundson
<david at davidedmundson.co.uk> wrote:
> 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
> easy.

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
there.

BTW, you can listen to the session at [1]

[1] http://mirrors.tumbleweed.org.za/uds-o/2011-05-13-12-55-desktop-o-kubuntu-lightdm.ogg

regards,
Harald



More information about the kubuntu-devel mailing list