discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XCode 5.x XIB support... a few thoughts aloud...


From: Gregory Casamento
Subject: Re: XCode 5.x XIB support... a few thoughts aloud...
Date: Thu, 3 Apr 2014 16:50:54 -0400

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 <ivan@vucica.net> 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" <greg.casamento@gmail.com> 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
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]