Re: New module proposal: LightDM

[Matthew Garrett <mjg59 srcf ucam org>]

On Fri, May 13, 2011 at 04:44:49PM +0200, Robert Ancell wrote:
> On 13 May 2011 16:01, Matthew Garrett <mjg59 srcf ucam org> wrote:
> > On Fri, May 13, 2011 at 02:59:06PM +0200, Robert Ancell wrote:
> >
> >> - I am confident that the LightDM architecture is simpler than GDM.
> >> Some indicators of this:
> >>   - Smaller code size
> >>   - Well defined interface between greeter and session
> >>   - Less dependencies
> >>   - Less internal interfaces
> >
> > The daemon side of LightDM (including the gobject bindings) is about
> > 10,000 lines of code, which compares to 35,000 lines in gdm. Are they
> > feature comparable? Does LightDM currently implement the same user
> > switching interface?
> 
> It has a different user switcher interface, but backwards
> compatibility is something I am looking into (as well as defining a
> XDG standard for display manager interfaces).

Standardising this behaviour would seem like an advantage, providing we 
don't have semantic differences that the desktops will want to rely on.

> > Practically speaking, in order to avoid feature regression the obvious
> > way to use LightDM would be to port the existing gdm greeter to the
> > LightDM backend. Who would be doing that work?
> 
> It certainly is an option.  I think the ideal solution would be to
> make implement a clutter based greeter as designed for GNOME 3 [1].
> While I will be working on LightDM for the next six months, I don't
> feel I have the time to make this shine and someone would need to
> volunteer for this work.

I'd expect that a prerequisite for adoption would be functional 
equivalence. If the greeter is to be maintained by some third party 
rather than yourself, how is the maintenance overhead reduced over using 
gdm?

> > This is a benefit, but I'm not sure it's a huge one. The platform in
> > general hasn't been designed with "Make it easy for users to write new
> > UI for existing applications" as a goal.
> 
> Sure, but I think the current solution has been held back by the
> difficulty of doing this.  We will want to revamp the greeter/shell in
> the future (or new technology might require it) and being able to do
> that easily is useful.

The greeter isn't just about presentation. There's a great deal of code 
in there that's tied into desirable features. If we move to new 
technology we'd presumably want to keep that functionality, so it's not 
obvious that implementing a new greeter would be easier than modifying 
the existing one.

-- 
Matthew Garrett | mjg59 srcf ucam org