Fred, I'm not sure it would need to involve the writing of tag classes as their is a definite pattern to how the elements in the XML are named. It appears as if any object with "id" present is mappable to an object within the NS set of classes. customObject = NSCustomObject, menu = NSMenu, menuItem = NSMenuItem and so forth. I also believe that the attributes are mappable to getter/setter properties in each corresponding class. It's not necessary, I believe, to write any tag classes since they would only serve as intermediaries between the actual objects and the XML. I'm going to remove the GSXibParser class from gui and revert the changers I made in GSXibLoader. I'm wondering if we shouldn't remove Xib loading from GUI entirely since few new apps are going to use the 4.6 format, but we also don't know how many apps are currently using it as it stands, so it may be better to simply leave it. You should see some commits tomorrow pursuant to this.
Regarding references, I had planned on storing any objects with "id" in a hash table as you suggested. Once I get everything pulled out you should see where it is. I am considering making it part of the plugin in Gorm for XIB files. Ultimately, nibtool will use GormLib and GormCore and Gorm's plugins to read the XIB. Let me know if you believe it's better to put it in it's own library. Greg On Thu, Apr 3, 2014 at 5:46 PM, Fred Kiefer <[email protected]> wrote: > Greg, > > I agree with you that the code to load and process the new XIB format > does not belong into gui itself. Your idea of just being able to load > the format and convert it into a NIB file sounds great to me. > When I first learned about this new format I compared it to Renaissance. > If we want to load it directly we will need similar extension code for > each and every class and that doesn't fit to well into gui. Maybe the > code in Renaissance may even be a nice guiding line for your > implementation of the new XIB file? > If you go that way you will have to write specific markup classes that > just take the tag name, attributes and elements from the XML and have > each transfer itself into the corresponding Cocoa class. The XIB format > is even a lot simpler than the Renaissance format. But as always the > details will be the hard bits. What about references? You will need to > store all decoded markup objects in a hash table, keyed on the id as well. > > There is a lot to do.I am willing to help and maybe others would like to > join in as well, > > Fred > > > > On 03.04.2014 19:54, Gregory Casamento wrote: > > I've been working on Xcode 5.x XIB support. Here are a few observations: > > 4.6 XIBs used the existing encoding keys to encode information, 5.x XIBs > do > > not. They appear to use a recursive/container driven approach which uses > > the getter/setter (properties) methods as keys to fill in the information > > in the objects from the XML. > > > > Because of this some methods, such as initWithCoder: will not be called > > while the model is being loaded. While we could add yet another section > to > > the existing initWithCoder methods, it seems pointless to do this. This > > might be a source of issues, but since the current Xcode/IB doesn't > include > > the concept of user defined palettes, this might not be much of an issue > > and should only occur in rare cases if at all. > > > > Additionally connections and related objects are contained within each > > object in the XML as opposed to referenced. This means that instead of > > having a pointer to an array of contained objects, those objects are > right > > there inside the containing object. For example... in a 4.6 XIB, there > > will be an array of menu items in the objects array (the objects array > in a > > 4.6 XIB or, indeed, a NIB file is the container which contains ALL > objects > > stored therein). The array will contain a set of references (by > position) > > to each menu item which is also stored at a given position in the objects > > array and the menu itself will reference the items array, by it's > position > > in the objects array. By contrast, in a 5.x XIB these objects are simply > > contained in the menu instance and those items contain any connections > they > > have to any methods. Objects are referenced by id and not position. > 5.x > > XIB files are, thus, fundamentally different from previous versions. I > > believe the only reason they still called them XIB files is because they > > are XML and generated by Interface Builder. Other than that they are a > > completely different format. > > > > Because of some of the above factors I've considered moving the code I am > > currently working on outside of GUI and making it part of GORM and > creating > > a tool which links to GormCore and GormLib to allow it to transform XIB > > files into .gorm files during a build. It is still possible to finish > the > > code and load them directly, as long as the above limitations are > > understood. > > > > I'm wondering if anyone else has any thoughts or feelings on this matter. > > If so, please make them known. > > > > Thanks, GC > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
