GSXibKeyedUnarchiver out of order reference bug

[BennyKJohnson]

I've encountered this bug in the GSXib5KeyedUnarchiver while working on porting Transmission Cocoa to GNUstep. It was discovered when GNUstep was incorrectly trying to resolve an IBOutlet with a string as its destination.

Problem:
If a referencing node such as outlet connection appears before the referenced node such as a custom object, the reference will fail to resolve. A concrete example of this would be an outlet element that has a destination id but the referenced node appears later in the file.

This is what appears in the MainMenu.xib file for the Transmission project. On lines 105 and 109, node 206 is referenced as the outlet destination.

The node with the id=206 appears much later in the file.

Expected behavior:
The Nib file should successfully resolve the referenced nodes regardless of the order that they appear in the file.

Possible solution:
Rather than process referencing elements as they are seen. Record them in an array. Once the entire nib file has finished being parsed then process these elements.

I should be able to address this bug but as I'm unfamiliar with the code base it might take me some time, so feel free to submit a fix.

[fredkiefer]

As you can see in the method -addConnection: in the file GSXib5KeyedUnarchiver.m GNUstep already stores just reference for connections that get resolved later in the processing (GSXibLoader -awake:inContainer:withContext:). This means there must be a different cause for the issue you are seeing. My problem now is that you did describe a proposed solution but not the symptoms themselves. As I don't intend to port Transmission to GNUstep I wont be able to reproduce this myself. Any further information from your side would help here.

[BennyKJohnson]

Hi @fredkiefer,

I will get a simple example together so that you can reproduce the problem. After some further investigation I worked out that the line at GSXib5KeyedUnarchiver:874 was causing the premature decoding of the outlets. It appears in the code if it detects a constraint it starts decoding it which causes other elements to be decoded. Commenting out this line fixed the error.

[fredkiefer]

I am not too familiar with constraints. As you can see in #64 they were merged without my approval and I even suggested to handle these more similar to connections. As far as I understand there is no real implementation behind this, so commenting out decoding won't loose any real functionality.

[gcasa]

Agreed, commenting that out is likely the best course of action. I apologize for doing that. I rushed this one. I hold myself accountable and strictly adhere to merging only when approved now. GC

[gcasa]

Was this ever fully addressed?

[gcasa]

Quick fix.