Re: UI change of "Languge" selection in gdm2

[George <jirka 5z com>]

On Fri, Nov 07, 2003 at 02:41:22PM -0800, Bob Doolittle wrote:
> I realize there is some precedent in current dtlogin behavior, but
> that is a very old legacy behavior which pre-dates current
> shared-server display usage, and today it is more of a handicap than
> an advantage.  We've been unable to change the behavior due to legacy
> usage for dtlogin.  Since we have an opportunity to change the model
> in ways that make sense for gdm2, I request that we do not follow this
> particular dtlogin path.  Instead, there should be no way to make
> persistent language changes to the greeter, except from an
> administrative tool that requires administrative authentication to run
> (e.g. root-edits to files in /etc/default :-).
> 
> If we accept this, then I see little point to having two options for
> language changes within the greeter.  There should be only one option,
> and it should affect the current instantiation of the greeter and any
> subsequent user session.  Nobody wants to use different languages for
> their greeter and their session, do they?

Yes, this is the best way.  Any sort of persistent change is a path towards
crackdom.  Also note that this is not as simple as it looks even for the
single session change which does seem like the correct way to do it (as
you propose).  That is you change the language and it sets the
language of the greeter.  Issues are:

1) You have to juggle two languages in the slave for that login screen.  Some
of the text comes from the slave (including pam) and you'd have to switch to
that language when any text that might go through to the user.  Text that
goes to the syslog for example needs to be in the system language ETC... In
short it is not just a matter of starting the greeter with the correct LANG
var set.

2) DoS is now possible.  If on a system I switch to Bengali or Chinese,
and then leave the terminal (assuming I'm in a country where most people
don't speak Bengali), nobody will be able to use the terminal without
restarting the greeter somehow.  This can be somewhat avoided by resetting
the language after a period of inactivity to the system language.  Obviously
this is still an issue nowdays, since my login will be in Bengali.  Plus I
could also screw with the session that the next person uses.  So it would be
desirable to reset ALL settings after a period of inactivity.

Overall it doesn't seem like such a high priority for me.  IMO this should be
better handled by setup once the user session starts.  Perhaps gnome-session
could ask for language on first boot.  Systems with many users in many
different languages is a rare occurance IMO.  Of course if someone submits a
patch that 1) is not persistent and 2) addresses both issues above.

Obviously since I'm of the opinion that even the current UI is a little too
much crack (as language selection doesn't seem to me something to be handled
by gdm) I'll be frowning upon any changes that propose to make that UI even
more complex.

> Perhaps the persistent-greeter-language-change-through-the-greeter
> capability could be turned on and off.  It would be acceptable to us
> if the system shipped with the capability enabled, which we could
> disable through a command-line tool during Sun Ray Server Software
> installation.  But this may be needlessly complex.  It would certainly
> create extra test burden and I'd be concerned about bugs slipping
> through the process due to lack of test coverage.

CRACK! :)

There is no need for this to be persistent.  It should be done from system
setup.  On single user machines, the language is selected during install (or
firstboot or whatnot) and so a language menu itself is a little redundant.
The only reason for a language menu that I see is for larger systems with
lots of users and in that case, you most definately don't want persistent
change.

George

-- 
George <jirka 5z com>
   In the fight between you and the world, back the world.
                       -- Franz Kafka