gnustep-dev
[Top][All Lists]
Advanced

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

Changes to XIB loader


From: Fred Kiefer
Subject: Changes to XIB loader
Date: Tue, 12 Apr 2011 11:24:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8

Greg send a bug report about the XIB loader code in gui not loading some XIB files. It turned out that the XIB loading code used a random load order for the objects (enumerating over the keys of a dictionary wont give you the order in which you added the elements originally), where we need to stick to the order given in the file to resolve references correctly. While working on this (locally of course due to the ongoing code freeze), I decided to change a few more bits in the code. The old code provided a virtual "root" node for the XIB data, this was wrong and contrary to what our other keyed unarchiver are doing. I removed that and now provide the actual root elements of the file. This change will require some adoption in the Gorm XIB loader. The problem now is that I don't want to risk our current release by adding this mostly untested changes. But if we commit these changes right after the release, Gorm wont work with the new XIB loader. Now the great thing is that the current Gorm XIB loading code never actually worked. Even with postponing this change things should never get worse than they are already. Is this strategy acceptable for all?

There is one other thing I would like to discuss. My changed code requires that the caller of the XIB decoding (Currently the class GSXibLoader and the corresponding wrapper class in Gorm) understand the order in which objects need to be decoded. (First "IBDocument.RootObjects" followed by "IBDocument.Objects") It would be a lot better to instantiate the objects in the order they show up in the file and only return these pre-produced objects when requested to decode them. But this may result in a few irrelevant objects being decoded and in the decoding happening too early. My original intention here was to properly implement reference decoding, so that it works even when the referenced object hasn't already been decoded. This was never needed when the objects where decoded in the correct order and I was to lazy to add code that would never get executed. Maybe I will have to rethink this position.



reply via email to

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