Hi Martin,

Thanks for your latest comments. This reply is long, but I sum up my
POV at the end.

On 2010-11-29 16:21, Martin Pitt wrote:
> ... I think we should still patch the Xsession script in the
> Ubuntu gdm package instead of this profile.d hacking; first, it would
> be a bit confusing for someone who looks at gdm's script,

I agree if you by confusing mean that it would be more difficult to
figure out, by following the code, what's going on at login. OTOH, to
non-language-selector users it would be less confusing, since they
wouldn't need to worry about my language_update() function etc. ;-)

> and second, it hasn't been tested with other login managers and might
> just break stuff there.

Don't see the difference in that respect between an Xsession patch and
sub-scripts. In any case we'll need to be attentive to those login
managers, that may be used by language-selector users.

> I think the gdm patch will be rather small, so that it won't be a
> burden to maintain.

Doesn't the maintenance aspect speak in favour of sub-scripts that
belong to the language-selector package? I mean, since it looks like the
Xsession related changes won't likely be accepted upstream, at least not
short-term, we are about to modify the locale environment handling for
language-selector users only. With the use of sub-scripts, i.e. most of
the code in the language-selector package, certain subsequent changes
might be easier to make.

>> ... I replaced the previously suggested Xsession
>> changes with two new language-selector files:
>> /etc/profile.d/gdm-lang-unset.sh
>> /etc/X11/xinit/xinitrc.d/language-environment.sh
> 
> That would again duplicate code, though?

Don't understand. To me it's a question about which file the code best
belongs to (unless you think of that tiny Xsession section with
LANG="$GDM_LANG", of course...).

> Also, it would mean that gdm
> behaves differently when language-selector is installed or not.

Yes. Isn't that what we want for the time being, considering that the
idea was rejected upstream?

> I'm not totally avert to this, but I'd rather avoid it. (See above)

The sub-script solution was triggered by Takao Fujiwara's response at
https://bugzilla.gnome.org/show_bug.cgi?id=633295. At first I too
thought it was hackish, but I have come to feel that the advantages are
not insignificant.
- We leave the GDM behavior untouched for users without
language-selector or with older language-selector versions.
- Easier to maintain if as much of the i18n related code as possible
resides in the language-selector package.

>>>  - in the second part of language_update(), why would $GDM_LANG not 
>>> be a valid locale? 
>>  ... 
>> I think that the reason why there is a need to ensure that LC_MESSAGES
>> is assigned a valid locale is that ~/.dmrc and /var/cache/gdm/$USER/dmrc
>> are now updated by language-selector when LANGUAGE is set.
> 
> That's the part I don't understand. The format of LANG and LC_MESSAGES
> is the same -- a valid locale string. There shouldn't ever be a change
> which sets "Language=" in .dmrc to a non-locale string (cf.
> compatibility to older gdm and other *dm); is there?

Hmm.. If I recall it correctly, we agreed a few weeks ago to
conceptually convert GDM's locale selector to a pure language picker, in
order to make it play well with the language tab in language-selector.
It should be noted that language-selector's language tab is not designed
to set LC_MESSAGES, but to build LANGUAGE lists. The language tab
menu includes both ll_CC combinations and pure ll options, and that's
the kind of values that has been passed to the dmrc Language field (and
with that $GDM_LANG) in all the variants I have uploaded the past few
weeks. Even if a .utf8 extension is appended, no testing of whether the
resulting string represents a valid locale is done, AFAIK.

To get a string that equals the name of a valid locale, and hence can be
assigned LC_MESSAGES, language-selector uses similar code with locale -a
etc. as you have noted in the language_update() function. Typically an
ll_CC combination plus .utf8 makes up the name of a valid locale, while
you need to have the program pick an arbitrary country code in the case
of a pure ll option.

The dmrc Language field and GDM_LANG serve the purposes of
* determining the pre-selected option in GDM's language picker, and
* holding the new value if another language is picked from the greeter.

For the above reasons, LC_MESSAGES should not be assigned the GDM_LANG
value just like that.

So, why doesn't language-selector pass the same string to dmrc as it
does to LC_MESSAGES? My reason for not wanting to do it that way is that
it would result in incorrect pre-selected options in GDM's language
picker. For instance, if you would drag "Deutch" to the top of the menu
in language-selector's language tab, you would see "German (Austria)" as
the pre-selected option at next login. Certainly not a disastrous bug,
but significant enough IMO to not introduce intentionally.

In other words, I suggest that we start using dmrc's Language field and
$GDM_LANG in a way that differs from the original intention, but only
for Ubuntu users with language-selector. As you pointed out above, we
would make GDM behave differently when the new language-selector version
is installed compared to when it's not, and that ought to take care of
the risks for backwards compatibility issues as well as issues with
other dms.

>> As regards efficiency ("expensive things"), please note that the
>> language_update() function is called only when the user changes the
>> language from the GDM greeter.
> 
> Thanks, noted. I agree that we can add some computational overhead
> just for this case.

Great! What's currently (in the version with extended use of dmrc) is
left at each login is a couple of relatively inexpensive (non-regex)
grep()s, in order to read the "Langlist" and "LCMess" values from
/var/cache/gdm/$USER/dmrc.

>> I'd like to raise a couple of Kubuntu related questions.
> 
> I'm afraid I don't know anything about the KDE bits; it's worth
> speaking to the kubuntu-dev folks about it. However, I think as a
> first step we should make these changes to /etc/gdm/Xsession first and
> see how it goes out in the field. Then we can see how to apply these
> to kdm and whether there's something to factor out. WDYT?

I brought it up now since Kubuntu is also using language-selector, and
there is a separate Kubuntu binary.

Only changing the Xsession behavior, without changing language-selector
at the same time, wouldn't make much sense, would it? But I'm in favour
of committing something very soon.

>> During our talk in #ubuntu-desktop last friday, you mentioned the
>> possibility to drop ~/.profile for storing the user language environment
>> and use /var/cache/gdm/$USER/dmrc instead.
> 
> Note that this was just a strawman idea,

Still a good one. :)

>> I think that may be a practicable approach with the advantage that
>> there is a safe method in place for writing to disk. I added the
>> keys "Langlist" and "LCMess" to dmrc and rewrote
>> language-environment.sh (attached).
> 
> It's an interesting idea indeed. I brought this up in the context of
> language-selector, to avoid having to parse/change ~/.profile there.
> Back then I didn't actually think about the gdm integration, but if it
> can be done in gdm itself, so much the better.

I saw it as a clever solution to our disagreement on the need to save
language changes to disk at login. While I find writing to disk to be an
important piece to complete the fix of the issues discussed in this bug
report and its duplicates, you have been reluctant due to the nature of
~/.profile, NFS problems etc. I haven't abandoned ~/.profile yet; LANG
is still set there (but it can of course be changed later).

> This needs to be tested with other window managers, though, that they
> don't stumble over these new fields.

The new fields don't appear automatically in the files - you need to
write to either /var/cache/gdm/$USER/dmrc or ~/.dmrc first. Then the
files update each other with changes. Therefore I don't think there is
such a risk. Or am I missing something here?

>> [ patch that adds new fields to dmrc ]
>
> This looks nicely generic.

Well, I can't program in C, but I know how to copy and paste. :)

> Would upstream consider taking this?

Good question. I noticed that the is_failsafe field is not included
upstream, so I figured there may be an Ubuntu specific patch for
gdm-session-settings already... OTOH, as far as I understand, additional
fields shouldn't hurt anyone who don't use them, so I suppose it may be
worth a try to approach upstream about it.


To sum it up, I feel ready to prepare final (almost) branches to be
merged into Natty. For reasons stated above, and for the time being, I'd
like

* that the dmrc Language field may be assigned values that may not
represent valid locales

* that the idea to extend the use of dmrc is partially (LANGUAGE and
LC_MESSAGES) realized now

* that language changes via the GDM greeter are saved to
/var/cache/gdm/$USER/dmrc

I believe that the apprehensions, as to undesired effects on other dms
and backwards compatibility issues, are sufficiently addressed. In this
context I'd like to emphasize:

* By using sub-scripts belonging to language-selector instead of
patching Xsession, we initially change the GDM behavior only for Ubuntu
users who have the new version of language-selector installed.

* Let's make language-selector keep updating ~/.profile with LANGUAGE
and LC_MESSAGES changes transitionally, even if it also writes to
/var/cache/gdm/$USER/dmrc. Doing so may prevent both undesired effects
to Kubuntu users and the kind of backwards compatibility issues in
networks that you mentioned.


That's my current view, but the decisions are up to you, of course.
Hopefully I have argued well enough to get your approval. :-)

Gunnar