Hello Gunnar, I see a ton of new MPs and replies here, so I'll reply/catch up with them one by one. So some of my replies here might already be obsolete now. Gunnar Hjalmarsson [2010-11-30 12:12 -0000]: > > 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. If you patch /etc/gdm/Xsession, it'll just affect gdm. If you add something to /etc/profile.d/ and xinitrc.d/, it will affect all login managers, and will even run for console and ssh logins. > Doesn't the maintenance aspect speak in favour of sub-scripts that > belong to the language-selector package? I don't think it makes much difference where the script changes are maintained (in gdm or l-s), but in gdm they'll only apply to gdm, which I think is the safer approach for now. There's another aspect to this: The upstream gdm Xsession script already sets $LANG. With the changes that you have in mind, it needs to stop doing that; with separate .d directory scripts, you can only additionally set $LC_*, but the original $LANG value is lost. > > 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? It sounds strange to me. Why would you desktop language suddenly change if you uninstall (or install) language-selector? I don't think that this meets the principle of least surprise. > >> 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. Right, but without upstream taking some of those more intrusive changes we need to have a compromise where we don't change the meaning of .dmrc. Since other DMs also use that file, we can't just redefine the meaning of the Language= option there anyway. > It should be noted that language-selector's language tab is not > designed to set LC_MESSAGES, but to build LANGUAGE lists. Correct, but that's orthogonal to gdm. language-selector has both a language list (for $LANGUAGE) in the first tab, and a locale picker in the second tab (for time, currency format, etc.). > 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. Right, and that's what I'm continuing to object to :) We can't do that only in Ubuntu without getting agreement between other users of .dmrc (kdm/xdm/lxdm/ltsp/..., presumably not all of them use .dmrc, though) > 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. I agree that this is confusing, but I think that's the kind of compromise we have to make if this is going to be a non-upstreamable change. > 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? I don't have a strong opinion here, but of course it would be better to be consistent with what gdm does. Especially since the language-selector-qt port should do pretty much the same as the GTK variant. > But I'm in favour of committing something very soon. Right, so let's keep the KDE discussion separate, and limit the changes to gdm for now? > > 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? I meant that if on one machine you use GDM and put a new field in your ~/.dmrc, and on another machine you use KDM, then KDM shouldn't suddenly act up on the new field. Since this is an ini-style file shared by different *dms, it should (and will) probably just ignore the new field. I just brought it up as something which should be confirmed by testing. > 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 This has my strong veto. I'd rather add a new LanguageList (or similar) field to it on demand. > * 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. See above. You'd also change behaviour for Kubuntu, ssh, and VT logins. > * 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. I agree. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)