LightDM-KDE

[David Edmundson]

On Wed, May 18, 2011 at 2:36 AM, Robert Ancell
<robert.ancell at canonical.com>wrote:

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

Sorry to hear that, hope you get well soon.

>
> 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 do sometimes wrap glib ones for example QtGstreamer, whereas othertimes
it's all new code pulling data from Dbus (such as Telepathy-Qt). Sometimes
(such as in Qt Core) functionality is written from scratch using the
relevant native APIs. So there's no "standard'.

What I'm concerned about is when you add extra functionality (for example
Grub reboot OS selection) into one of the library it has to be written out
in both - and we have the potential to have bugs in one and not in the
other. It will be hard to sort out bug reports when we have two client
libraries potentially doing different things - especially when the bug
report doesn't indicate which library is being used.

If we are treating them as first class citizens (which so far has been the
case, thanks ever so much for updating the Qt libs) then maybe this isn't a
problem :-)

---

KDE people there is a slightly nicer Qt demo greeter here:
git://anongit.kde.org/scratch/davidedmundson/kde-greeter.git Still purely
demo-ish code to test the lib.

Robert - are you happy for the Qt demo greeter to have KDE
code/dependencies, or do you want to keep it Qt only?


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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20110519/7eb40a1a/attachment.html>