LightDM-KDE

[Robert Ancell]

Hi David,

Sorry for not notifying you of the session.  It was scheduled very late
(i.e. just after the main LightDM session on Thursday) and I ended up
being sick on Friday so it wasn't running at 100%.

Regarding the D-Bus interface to the daemon - originally there was not
going to be any client libraries - the interface would be all D-Bus to
the daemon.  The client libraries were added to make this interface
easier to use; then they had additional functionality added; then they
got to the point where so little of the communication was to the daemon,
and securing that communication through a pipe rather than using D-Bus
for convenience became more important.

There are two libraries, a GLib based one (no GTK dependency), and the
Qt one.  Yes, they contain the same functionality, which has some
overhead.  However, wrapping the GLib one would lead to an API that
doesn't feel Qt (as far as I know - I'm quite new to Qt).  I'm
completely happy to support both GLib and Qt to the same level (i.e. Qt
is a first class citizen here), and both these libraries will be fully
unit-tested.

We'll almost certainly use a Qt based greeter for Ubuntu for Unity 2D,
and this will be a fallback greeter when using the Unity 3D greeter. 
I'm not sure how KDE does fallback or detects if it can't use Plasma but
this may be a solution for KDE too.

--Robert

On 05/18/2011 01:06 AM, David Edmundson wrote:
> Hey all,
>
> 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. 
> 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. 
>
> 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.
>
> 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.
>
> Regards
>
> David Edmundson
>  
>