Ivan, Yes, indeed, that was the idea. Make it like ibtool on the Mac which is used to “compile” XIBs into NIB files during the build phase of the xcodeproj file processing. We could add it to gnustep-make and to the buildtool/xcode library to perform the same task. I started a tool with the intention of making a command line version of Gorm some time ago called “nibtool” in the repo, but never got very far.
* AS AN ASIDE: The nibtool utility is one of the reasons I refactored Gorm into a set of libraries so long ago because I wanted to make it possible for other applications or tools to take advantage of Gorm’s functionality. It was also done to make Palette’s possible, but to date, unfortunately, no one has created pallets for Gorm except for GDL2 and a few other internal ones. I am going to send out an email with some of my thoughts on the future of Gorm later tonight. I have big changes in mind. :) We *CAN* still have it load the XIBs directly, but with the KNOWN and DOCUMENTED caveat that some edge cases will not be covered. So we could do both. I just wanted to share what I’ve learned thus far. I should be done with this fairly shortly under any circumstances, time permitting. Gregory Casamento GNUstep Maintainer/Lead Developer greg_casamento (Skype) (240)274-9630 On Apr 3, 2014, at 4:34 PM, Ivan Vučica <[email protected]> wrote: > I found loading xibs directly in a -gui based application exciting, but > gutting it out into Gorm (or even better a separate tool ran during build > phase) is fine for any non-edge-case workflow that I can think of. > > Edge case I can think of is "hey, let's replace .xib directly without > rebuilding the app, for easier debugging". > > sent from phone > > On Apr 3, 2014 6:54 PM, "Gregory Casamento" <[email protected]> wrote: > Hey guys, > > 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 > -- > 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 > _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
