Re: Changes to XIB loader

[Gregory Casamento]

Fred,

On Tue, Apr 12, 2011 at 5:24 AM, Fred Kiefer <address@hidden> wrote:
> 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?

This should be fine.   While there is code in Gorm to load XIBs, I am
planning on disabling this functionality in Gorm for the next release.
 Once the changes to fix XIB loading go into the trunk, I will start
fixing the XIB reader plugin in Gorm so that XIBs can, at least, be
read.

> 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.

Theoretically, unarchiving IBDocument.RootObjects should get all of
the objects which are needed to run in a live application since the
archiver should walk down the object graph unarchiving each object
(node) as it goes along.   The only reason the code would need to read
IBDocument.Objects is when/if there is an unreferenced object in the
graph someplace which the user added in IB/Gorm, but didn't do
anything with.

Later, GC
-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)