[Top][All Lists]

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

Re: problem loading GWorkspace DesktopPreferences Gorm file

From: Riccardo Mottola
Subject: Re: problem loading GWorkspace DesktopPreferences Gorm file
Date: Tue, 24 Apr 2012 21:53:38 +0200
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14


Fred Kiefer wrote:
On 24.04.2012 01:21, Sebastian Reitenbach wrote:

When a developer runs SVN, then that's fine. He usually knows, when using a new class/method in the code, and they can decide, whether the next release of their app will be before or after the next core release. But those binary changes to the Gorm files, they are not so obvious. This obviously trapped some long time
GNUstep developers.
Does there exist a technical way that could prevent this happening in the future? So not only make the core libraries backward compatible, but also potentially more future compatible? Or is it just the developers discipline, in case he wants to release Apps against the latest releases,
that he is supposed to use the releases while developing?

I'm just thinking, whether Gorm for example could open a Gorm binary file, and save the representation as a .plist file? Which then in turn could be opened by Gorm again, to save it again as a binary again? That would probably make porting Gorm files to older versions of gnustep easier.

There is one more option we could think about here. We could change the method NSArciver -encodeArrayOfObjCType:count:at: to be backward compatible. That means this method should store all array sizes that fit into an 32 bit integer in that space and only use the new technique for bigger sizes. This will mean that we'll have two version checks instead of one and of course another version increase in base. But all these drawbacks seems minimal when compared to the current situation where old code wont be able to load newer Gorm files.

Richard, what is your position on all this? You are definitely the expert here and we may have overlooked a much cleaner solution.
I think Sebastian found a problem. First it is ture that both Laterna Magica and PRICE I jsut rleased won't work on current GNUstep. You just need top open and save gorm and it will be incompatible, even if the same "features" re used. I don't kno how IB handles this on mac, but except for the major format change with 10.2 (and one can still select the older format in 10.4) as long as you don't use "new" features NIBs are reasonably portable. So working in that direction might be interesting.

The problem is that essentially I always track core from SVN and encoding is given by that, even if I don't update gorm, i'm "tainted".


reply via email to

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