[LightDM] lightdm at lists.freedesktop.org

[PCMan]

The .profile is only loaded by sh.
If csh is used or bash is used, .profile is not loaded.
Using session_wrapper is not a good solution as the script is
distro-specific.
So there is no reliable way for a greeter to set a language even if I write
into .profile.
It's true that setting language is not the responsibility of display manager
most of the time. However, gdm does this for years and nobody complains of
that. It's still a nice feature to have. It's the responsibility of login
shell to set the environments under console. Under GUI, the login manager
becomes the graphical one so it's not quite unusual for a dm to set the
required environment.
Relying on .profile can be distro-spefiic and it's not reliable. This is not
something upstream authors can do. So now the situation is I coded something
which doesn't work and it requires the packagers to patch it heavily to
provide the features wanted. Bad news for upstream authors. :-(
Are there any cleaner or more elegant alternatives to make language
selection in greeter work?

On Mon, Aug 22, 2011 at 8:03 AM, Robert Ancell <robert.ancell at gmail.com>wrote:

> On 19 August 2011 00:52, PCMan <pcman.tw at gmail.com> wrote:
> > I just migrated my own GtkBuilder-based greeter to LightDM 0.9.x.
> However, I
> > found that language selection is no longer available. We relied on this
> > feature in the previous version. The feature is also supported by gdm and
> > lxdm. With LightDM 0.9 supporting this is not possible. I read the source
> > code and found that "Language" value in .dmrc is not used. So there is no
> > way to configure language for the selected session.
> > In NEWS file of lightdm, I noted that this is deliberately removed and
> users
> > should set locale in .profile. However, .profile is not always loaded
> > depending on the distro/environment used. Moreover, this requires that
> users
> > edit config files manually. Is it possible to restore this feature in
> > LightDM or at least give us other ways to do it?
> > If LightDM is not going to support this, will LightDMLanguage be removed
> > later? If Language defined in .dmrc is not reference by lightdm, will
> > lightdm_user_get_language be removed?
> > Besides, I found a bug in LightDMUser. Every call to lightdm_user_get_*
> > loads dmrc again and causes memory leaks. Please check this part. Thanks.
>
> lightdm_user_get_language is not going to be removed, as it is useful
> even if you can't set the language for a user.  For example selecting
> a user should change the greeter to their language.  LightDMLanguage
> will not be removed as it would break API.
>
> The easiest way to set the locale is to set it in the session wrapper
> (session-wrapper in lightdm.conf).  If you want to grep the .dmrc and
> use that then that would work, but I'd recommend you load ~/.profile
> and have that set by your locale configuration tool.
>
> Language is a messy problem (as shown by the endless problems we have
> had in Ubuntu trying to get it working reliably)
>
> Problem #1 is language != locale.  If the greeter can only choose
> language it can't configure all the detail required to set up a
> locale.  If you were to make it support everything it would be too
> complex.  If you allow the greeter to set arbitrary environment then
> that ignores the problem and makes it inconsistent between different
> distros.
>
> Problem #2 is locale is not just for GUIs.  It really should be
> external to the display manager and applied to all logins.  It really
> shouldn't be in the .dmrc.
>
> Problem #3 is who is responsible for setting the locale environment
> variables?  The environment is set up like this:
> - LightDM sets a default environment
> - PAM sets more environment
> - LightDM sets some GUI specific variables, e.g. XAUTHORITY XDG_SEAT_PATH,
> ...
> - Environment is set in the session script (session-wrapper config
> value in lightdm.conf, or /etc/gdm/Xsession in GDM).
>
> Ideally LightDM wouldn't set have to do the default and it would all
> come from PAM.  The locale should come from PAM or from the session
> script if that isn't possible.
>
> Thanks for the tip on the memory leak.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20110822/53797e06/attachment.html>