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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
