Re: [Discuss-gnustep] Localization

[richard]

On Thu, 21 Sep 2000 12:12:34 -0500 (CDT), jagapen@home.com wrote:
> Oh BTW, a while back I re-wrote a huge chunk of NSUserDefaults,
> because the old code is a minor disaster with regards to the behavior
> described in Apple's documentation.  (I've tested it for a long time now,
> so unless anybody has objections, I'll check it in soon.)

Well - I'd strongly object if it breaks OpenStep compatibility or removes
existing functionality.  IMO, MacOS-X compatibility needs to be added in a way
that's compatible with OpenStep (or is a user selectable option).

> I took out the
> code that tried to get the locale from the environment, because it's
> GNUstep-specific.

I don't see that that is an objection - this is merely attempting to avoid
the necessity of the user having to set their defaults value - ie it is a
feature
to make GNUstep apps easier to use in a non-GNUstep environment.

> Furthermore, I'm not conviced it's a good idea.  If we
> do the check in a method that gets the user's preferred languages, that
> doesn't account for applications that grab the NSLanguages defaults key
> directly.

Agreed - that probably means that the code is in the wrong place - it should
probably reside in the +initialize method, and be used to set the NSLanguages
key in NSRegistrationDomain.

> It's not at all a good idea for NSUserDefaults to re-write the
> NSLanguages value, because it violates the principle of least surprise.
> (E.g. if the user sets the environment differently for one application,
> it'd re-write her user defaults for all applications!)

But I'm sure that the existing code doesn't do that, and the objection
doesn't apply to setting NSLanguages in NSRegistrationDomain, since this is
not a persistent domain.

> This is another instance of a problem I've seen come up more lately:
> GNUstep-as-environment vs. GNUstep-as-API.  The current GNUstep code base
> leans heavily toward environment.  To wit, it draws its own menus, its own
> widgets, has its own event loops, its own threads, and of course maintains
> its own user settings database, et cetera.  IMHO, GNUstep-as-API requires
> some entirely new code.  E.g. NSUserDefaults-gnome.m, a front-end to the
> GNOME user settings system, or NSUserDefaults-win32.m, a front-end to the
> registry, leaving NSUserDefaults.m alone as part of the GNUstep
> environment.

I think I only partially agree with you here -
I have no problem with the notion of multiple optional NSUserDefaults systems
that wrap 'native' systems in the OpenStep API.  The reason they aren't there
is that nobody has contributed them, not that there is any objection to them.
But I don't agree with the conclusion that the GNUstep codebase leans away
from the API and towards the environment.  Where GNUstep differs from Gnome,
it's usually because GNUstep got there first and the Gnome stuff just didn't
exist when it was written - and since the GNUstep code works, there's little
incentive to change (perhaps we should be contributing code to the Gnome
project to let them use NSUserDefaults).  Where win32 is concerned, there are
so few win32 users that work is still being done on basic parts of the port.
Basically, GNUstep is an implementation of the API that tries to be as
portable as possible - optional code to integrate in to more specialised
environments is desirable, but surely can't be highest priority.