LightDM-KDE

David Edmundson david at davidedmundson.co.uk
Tue May 17 23:56:39 UTC 2011


On Wed, May 18, 2011 at 12:26 AM, Harald Sitter <sitter.harald at gmail.com>wrote:

> 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.
>
> Sorry, that came across really whiny - it wasn't intended.

I have been at the pub, I'm going to blame it on that.


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


My bad, I worded that very badly. It's copied and pasted native C code, that
is then either bound to GTK in the GTK lib, or Qt in ours. There's no
lib-dependency.
The point is that it's copied and pasted code. That's never a long term good
sign. We don't want the two going out of sync.

It does seem like the LightDM backend suddenly lost it's DBus interface and
I'm not sure why.


> > 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.
>
>
What I would like to see is a list of things we want to do with the greeter
- and then we can discuss the best solutions for doing it. I'm talking to
Alex Fiestas on IRC, I'm not /that/ against plasma, I just want to the right
solution chosen properly, not because it's the latest buzzword.



> 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


Will do, Thanks.

Can I propose that:
  - We all get our thinking caps on, come up with ideas for "our ideal login
manager" (including the KCM)
  - We get some idea from Robert (and anyone else on the main LightDM side)
as to what upcoming changes in the backend we can expect.
  - I'll tidy up the library code, and make it both QML and Plamsa ready
(pretty much the same thing, more models, more property macros etc.)
  - From here we have an IRC meeting to discuss the plan.

>
>
> regards,
> Harald
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20110518/5a19fee8/attachment.html>


More information about the kubuntu-devel mailing list