|
| From: | Gregory Casamento |
| Subject: | Re: XCode 5.x XIB support... a few thoughts aloud... |
| Date: | Fri, 4 Apr 2014 00:24:32 -0400 |
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.GregOn Thu, Apr 3, 2014 at 5:46 PM, Fred Kiefer <fredkiefer@gmx.de> 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
Discuss-gnustep@gnu.org
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
| [Prev in Thread] | Current Thread | [Next in Thread] |