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 -- Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing https://bugs.launchpad.net/bugs/553162 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
