Comment 8 for bug 1069494

> Chosen session seems to be applied regardless of whether it was written to ~/.dmrc

I just had another go at this using lightdm 1.12 and lightdm-gtk-greeter from Debian experimental. Indeed, the ~/.dmrc file is now written again but, like you say, lightdm is completely ignoring what was previously written to ~/.dmrc. Even worse, the settings from the previously logged in user remain such that if your preferred session is KDE and the previous user used MATE, your session will automatically set to MATE instead to KDE.

It's sad that this still hasn't been properly addressed as it makes lightdm pretty much unusable in corporate environments where people don't have a personal workstation, e.g. a university or school.

With old versions of gdm (<= 2.20), session management worked like a charm in corporate environments. There was a default session and language that was started when a new user logged in - regardless on which machine on the network - when no ~/.dmrc was found.

If the user then decided they would want a different desktop environment/window manager or language, they could change these values once during login and gdm would write them to ~/.dmrc and restore these settings on subsequent logins - again, completely independent what machine on the network was used.

Then someone had the genius idea to completely shove the ~/.dmrc concept and came up with the ingenious "accounts-service-daemon" while completely ignoring the fact that people might change their workstation in a corporate environment as this daemon is constrained to local use.

Thus, when a user set their preferred default session and language, it was rather like gambling whether their preferred session and language would be loaded when logging the next time as it depended on the fact whether they had used this machine before and whether they actually already set their current preferred session and language on this machine.

The current version of lightdm does not improve this situation really. It does indeed write the settings to ~/.dmrc, but never reads them which makes the whole thing pointless. To be honest, I am rather surprised that this isn't handled with higher priority. This is a fundamental and very annoying problem that really needs to be fixed.

In my opinion, a display manager should always be able to query a user for their preferred language and desktop environment/window manager before logging in, then save these values in a decentral location, e.g. the home directory, then restore these preferred values at next login.

GDM3 has similar problems in this regard and I am surprised that RedHat hasn't addressed these issues yet. But I guess they will postpone it as long as possible until some "strategic customer" complains such that the GDM3 developers fix the problem - which they have been ignoring for so long - within 1-2 weeks (they did exactly that with a serious bug in gvfs).

Adrian