Hi Martin,

Thanks for your comments! Before replying to some of them, let me say
that I finally realized that the .d/ sub-scripts solution I suggested
previously was too obfuscated. Whatever advantages I saw, they could not
justify the resulting obfuscation. All code in a project like this has
to be reasonably easy to understand and maintain.

I'm not sure, but judging from some of your comments, I have a feeling
that even you had some difficulties in seeing through what the code
actually did. My fault, in that case; sorry.

Besides my replies below, I have added a comment to the GDM merge
proposal.

On 2010-12-07 10:34, Martin Pitt wrote:
> 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.
> ...
> 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.

I believe that I had taken care of both those aspects. The code in
/etc/profile.d/, which would have run before the spot where Xsession
sets $LANG, looked like this:

    if [ -n "$GDM_LANG" ]; then
        export GDM_LANGUAGE=$GDM_LANG
        unset GDM_LANG
    fi

The code in xinitrc.d/ would not have done anything but a variable test,
if [ -n "$GDM_LANGUAGE" ] had returned false.

Even if it's history now, I'd appreciate a hint if I missed anything.

> ... 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.

I didn't know that other DMs use the .dmrc file; thought it was a GDM
related file like the GDM_LANG variable. Hmm.. Spontaneously I don't
think it's an issue that hasn't already been taken care of, though,
since language-selector updates .dmrc only if GDM is running. Other
login managers can safely keep saving its settings in .dmrc.

I removed a section, where you further emphasize that we need to prevent
undesired and/or surprising effects to other login managers but GDM. On
that we are 100% agreed. My apologies if I have given you some other
impression.

Please note that the "redefinition" I suggest would only apply when GDM
and language-selector play together. Replace GDM, and l-s stops writing
to .dmrc. Remove l-s, and GDM falls back to its original behavior. No
harm done.

>> 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.

Compromising is excellent when the wishes are irreconcilable. Honestly I
don't think they are in this case.

> ... let's keep the KDE discussion separate, and limit the changes to
> gdm for now?

With Arne's input and my further studying of the code, I now feel quite
comfortable that there is no urgent need for any KDE discussion. The
KDE/Qt version of l-s simply don't call the l-s functions that write
user settings to disk. That's true both for ~/.profile and ~/.dmrc.

>>> 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.

Now I see and agree.

>> I'd like that the dmrc Language field may be assigned values that
>> may not represent valid locales
> 
> This has my strong veto.

See above.

> I'd rather add a new LanguageList (or similar) field to it on
> demand.

Actually I played with that thought when preparing the current branches,
but concluded that there is no need. Convince me that I'm wrong, and
I'll be happy to do some copy-n-pasting again. ;-)

> Unsubscribing sponsors, for the record. I think the discussion here
> has become way too complex, this will be handled between Gunnar and
> me now.

Sounds reasonable to me. Is there a more appropriate place than bug
reports to hold this kind of complex (at least for a newbie like me)
design discussions? #ubuntu-desktop is excellent as a supplement, but I
for one wouldn't feel comfortable with IM only in this case, since I
often need time for reflection, testing etc. before replying.

Rgds,
Gunnar