Just being pedantic... their = there
My goodness I need to proofread sometimes. :) I've gotten lazy because the iPhone usually corrects things as I go. The curse and wonder of great technology that ultimately makes us stupid. ;) Greg On Thu, Apr 3, 2014 at 11:16 PM, Gregory Casamento <[email protected] > wrote: > 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 > -- 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
