[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Global Defaults (Re: Associating bundle directories with app)

From: Richard Frith-Macdonald
Subject: Re: Global Defaults (Re: Associating bundle directories with app)
Date: Fri, 21 Jan 2011 15:27:28 +0000

On 21 Jan 2011, at 12:51, David Chisnall wrote:

> On 21 Jan 2011, at 12:41, Niels Grewe wrote:
>>> We have system-wide user defaults settings. 
>>> We don't have system-wide app/service caches because (as mentioned earlier 
>>> in this thread), there's no point, apart from some potential performance 
>>> gain.
>> Yes. I got that now (my mail somehow was delayed for about a day). I
>> will start telling people about the GlobalDefaults.plist when somebody
>> asks me awkward questions again…
> I can't remember if this has been asked before, but is this a single file, or 
> can we scan a directory for plists providing global defaults?  For packagers, 
> the latter is a lot more useful - they can then add and remove defaults 
> trivially.  For example, when you install a theme bundle, you can set it as 
> the global theme, when you uninstall the theme, you unset this default.

Nice suggestion ... I added it.
So now we have a GlobalDefaults subdirectory into which packagers can place 
.plist files ... and have have all those files merged into the GSConfigDomain 
of the defaults system.
But we still keep GlobalDefaults.plist and merge that into the defaults system 
after the files in the subdirectory, so this can continue to be used for 
general system settings while the subdirectory can be used for package specific 

> This is nontrivial to implement though.  A typical use-case would be 
> installing a user appkit bundle - you'd want to add this to an array in 
> defaults on install or remove it from that array on uninstall.  Can plmerge 
> or similar do this, and is this documented somewhere that's easy for 
> packagers to find?  

No, plmerge doesn't do anything like that ... I guess we'd need another tool 
(or perhaps better, to extend plmerge to allow control over how/where things 
are merged).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]