[Top][All Lists]

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

Re: ~/GNUstep/Defaults/.GNUstepDefaults

From: Richard Frith-Macdonald
Subject: Re: ~/GNUstep/Defaults/.GNUstepDefaults
Date: Wed, 27 Nov 2002 14:51:49 +0000

On Wednesday, November 27, 2002, at 02:19 pm, Richard Frith-Macdonald wrote:

On Wednesday, November 27, 2002, at 12:08  pm, Manuel Guesdon wrote:

I've found a problem using an application compiled with a previous version of core/base (around
jully 2002).
A new application has modified ~/GNUstep/Defaults/.GNUstepDefaults and make the dictionary unreadable by the old application (sorry, I haven't kept the modified file but it was a number coded as 7200 in previous version now coded <*I7200> or something like that).

It take me some time to guess why the application failed to run.
So is it possible to add versioning system in this kind of file so an new application won't badly
modify this file when the file version is older ?
Or use different file names for incompatible version
(~/GNUstep/Defaults/.GNUstepDefaults.x.y) or something else.... ?

Unfortunately the plist format (the old one, not the xml one) contains no provision for versioning ...
perhaps we should move to the new xml format for defaults?

Now, I have to make ~/GNUstep/Defaults/.GNUstepDefaults owned by root, writable only by the owner and readable by everyone (pplication fail to if it can't read the file) so old and new application can run..

Unless you use statically linked applications, your old apps can just use the new library and work with
the new format, so I didn't think this was likely to be a big issue.

Also, with the very latest CVS, the NSWriteOldStylePropertyLists user default should be honored - so you should be able to use that to force compatibility with apps that are statically linked to an older
version of the library.

reply via email to

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