Re: New module proposal: LightDM

[Ray Strode <halfline gmail com>]

Hi,

On Fri, Oct 22, 2010 at 5:31 AM, Josselin Mouette <joss debian org> wrote:
> Le vendredi 22 octobre 2010 à 01:17 -0400, Ray Strode a écrit :
>> Using GNOME session / g-s-d /etc  is one of GDMs main features.  The
>> point is for there to be consistent experience on the login screen and
>> in the session.
>
> That, I fully agree with. This is a major feature of GDM, that makes
> extending it easy and makes a11y support a breeze.
>
> It’s really a shame that LightDM doesn’t re-use this concept.
Right, GDM used to work the way LightDM apparently works now, and it
was changed because this way is better.

>> Anyway, I'm obviously in favor of keeping GDM in GNOME.  I admit it
>> has some baggage (some of it removed and added back later by popular
>> demand), but overall GDM is in really good shape as a project.. FWIW,
>> your various patches over the years have been a part of getting GDM to
>> where it is.
>
> I wouldn’t really call it in “good shape” from a distributor’s point of
> view. We have to include an ever-growing number of complex patches just
> to have the features that we consider essential, and development
> upstream is happening faster than the pace at which we can get these
> patches merged.
I understand this point--maintaining a load of patches can be totally
unfun.  We discussed this before on gdm-list and I think we've made
progress on that front since then.  If you drop by #gdm and ping me,
we can figure out what to do about your remaining patches.

> This situation is not new and we also carry too many
> patches in the 2.20 branch, but it’s not getting better; the sole 2.30.2
> → 2.30.3 upgrade included larger changes than all our patches added.
Sure, but those changes were important bug fixes and performance
enhancements.  I realize even if the changes were "worthwhile" it
doesn't make maintenance for you any easier if you've complex patches
to rebase, though.

> Having had to deal again with GDM’s labyrinth of classes, I came to the
> conclusion that Robert’s decision to restart a project from scratch was
> the right one.
GDM does have a lot of code, but I'm happy to explain any parts of the
code that seem confusing.

I will say there are some classes in there that aren't compiled in.
We could probably cull some of the excess fat to make it easier to see
the active code and just add it back from history when if they become
important again.

One example of something that's #if 0'd out "factory mode".  This is
where GDM always runs in the background on a VT and the user is sent
to that VT when ever they need a login screen.  This helps fast user
switching cases, and potentially paves the way for "trusted path"
password dialogs (which I think Robert was alluding to as a potential
future feature for LightDM).  That's something we could  potentially
drop for now.

> This means we don’t have the same priorities for GDM development, and of
> course it’s fine; you’re doing whatever you want with your own project.
I don't see GDM as "my project".  I see my work on GDM as way of
helping GNOME.  I do see GNOME as "my project" (well "our project")
though.

Again, I think one of the most important features of the display
manager is "integration".

We have to stop thinking about GNOME as this thing layered on top of
the OS, and start thinking of it *as the OS*.  We need to be able to
rely on important components being available and we need to leverage
their presence to provide a slick, coherent experience to the user.

As an example, the user switch applet is being moved to gnome-panel
(and a comparable version already exists in the shell).  Another
example is the accounts-dialog (which is slated to go into
control-center pretty soon I think.  see the thread i posted about
accounts daemon a few days ago) is used to configure things like
"Automatic Login".

This is all under the umbrella of providing a consistent, unified
experience to the user.  The "core" of gnome shouldn't be hot
swappable--it defines what gnome is.  I'd say the login experience is
central to the core user experience.

> But LightDM seems to focus much more on features that do matter for us.
Which features are those?

I think there may still be some lingering unhappiness about GDM losing
features (like the themeable greeter) when it was reinvented in 2.22.
Some of the criticism then was fair criticism and we worked hard to
add back the important things in a way that makes the most sense.  We
didn't add back the themeable greeter for good reasons.  It had
bizarre rendering bugs, an underspecified file format, and also wasn't
accessible.  GDM had to ship with a separate,"plain greeter" that
wasn't enabled by default in most distros for users who wanted an
accessible login.  That's not very courteous and it doesn't fit in
with our ideals of "universal access".

Now we have a greeter that's accessible, uses the core features of the
desktop, uses the same theming system as the rest of GNOME, supports
the same animated wallpapers, etc, as the rest of GNOME.  It''s
everything the themable greeter could never be.

I also want to say something slightly off-topic regarding "impulse to
change".  A lot of users hate when things they use get changed.  It
screws up their workflows, etc, and so many changes are controversial.
 Often there's a gut reaction "can you provide a way for me get things
back to the old way from the new way".  I'm sure a lot of people on
this list know what I'm talking about. For some reason, that same
impulse doesn't seem as strong when users change to different
functionally similar apps.  What I mean is, it's not okay if App A
changes the way something works or removes a feature, but if App B
never provided that feature in the first place then the user may
switch from App A to App B and be quite happy (even though App B
completely changes their workflows!)  I've never understood this, but
I've seen it happen a lot (not talking about LightDM and GDM in
particular here, just an off topic side note)

--Ray