It doesn't make us stupid, it lets us focus on bigger and more important things than small details :)
-- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Apr 4, 2014 at 1:24 PM, Gregory Casamento <[email protected]>wrote: > 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 > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message.
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
