Re: Problem with NSColor/NSString initialisation

[Fred Kiefer]

The problem that NSColor was unable to convert a string representation
to a NSColor was caused by a totally different reason than what I was
looking for. It is my C Local environment that gets it wrong. That is
also the reason why none of you could reproduce it. 
Here is what I did get when adding a few NSLog() statements into the
colour conversion function:

fred@hugo:~/GNUstep/decimal > openapp cell.app/
Apr 21 16:49:53 cell[10771] The current local is de_DE
Apr 21 16:49:53 cell[10771] String without prefix 0.000000 0.000000
0.000000
Apr 21 16:49:53 cell[10771] String 0.000000 0.000000 0.000000
Apr 21 16:49:53 cell[10771] System color 'controlTextColor' has bad
string rep -
 '0.000000 0.000000 0.000000'

When I added the NSLog call in my main function I did get:
Apr 21 16:50:44 cell[10949] The current local is de_DE
Apr 21 16:50:44 cell[10949] String without prefix 0,000000 0,000000
0,000000
Apr 21 16:50:44 cell[10949] String 0,000000 0,000000
0,000000                   

Somehow GNUstep sets up the C Local on the first call to NSLog, so when
I did insert this call the float representation stored for the colours
includes commas and will be interpreted later on correctly by sscanf().
If the call comes a bit later the initialization of the colour strings
has been done with the standard local, and cannot be interpreted
correctly by sscanf() later on.

I see two solutions to this, we either drop the standard setlocal()
call, which would eliminate all these problems, but would also reduce
the functionality of GNUstep. Or we make sure the the setlocal() call is
made before any local information is used. For NSColor this can be done
very easily, so I added that code (a call to [NSUserDefaults
standardUserDefaults]) here.

Fred