Re: Objective-C 2.0 and other new features in Leopard

[Richard Frith-Macdonald]

On 12 Nov 2007, at 21:53, Fred Kiefer wrote:

> Stefan Bidigaray wrote:
> > That reminds me of another point worth discussing... the defaults
> > system.  What you're saying here is not simple to do exactly  
> > because the
> > user HAS to change the defaults themselves.  Take for example GTK+
> > settings, all a distribution have to do to get a new look is add the
> > file $SYS_CONFIG_DIR/gtk- 2.0/gtkrc.  If the distributor, for  
> > whatever
> > reason, decides to change the standard theme all they have to do is
> > write a new file and replace the old one.  Under GNUstep, on the  
> > other
> > hand, there's no way around the fact that GNUstep doesn't offer a  
> > global
> > configuration file.  If a distributor wants a default set of  
> > settings,
> > they have to come up with a way to write defaults to every user,  
> > while
> > at the same time making sure they don't override the user's own
> > defaults.  In my opinion, someone should be able to at least set
> > NSGlobalDomain setting under a global file.
> >
> > I brought this up almost a year ago, and remember that the issue was
> > that NSUserDefaults wasn't set up to have more than 1 file and so  
> > would
> > need to be rewritten.  Since then, I've tried playing with it  
> > (seeing as
> > I have to come up with something for my ScreenSaverDefaults class)  
> > and
> > I'm trying to understand if better so that I can do something  
> > about this.
> Yes, I also think about user defaults from time to time. Splitting  
> them
> up into different files for example, so each application could ship  
> with
> a separate default setting. Having a multi level lookup also sounds
> interesting, but will require a bit more thinking.

Actually, the current code (since about 18 months ... before the  
1.13.0 release) already allows you to set up system-wide defaults by  
putting them in the GNUstep.conf file (and/or on a per-user basis by  
putting them in the user's GNUstep.conf file).
However, the defaults added there are limited by the parsing rules of  
that file (which is sourced by /bin/sh and make) so you can  
occasionally have a situation where an app uses a default name which  
can't be configured that way.
Removing that limitation by adding another file would be fairly easy,  
but would obviously have to wait for a new release ... however for  
apps which don't use spaces or other odd characters in their default  
keys, current and previous releases should work just fine.