Top level objects in the nib are the responsibility of the controller. That is to say that if you load a nib from MyController then any and all top level objects in that nib should be released by MyController when it deallocates itself.
On Sat, Mar 27, 2010 at 9:20 AM, Wolfgang Lux <wolfgang....@gmail.com> wrote: > Fred Kiefer wrote: > >> Before FOSDEM we were planing a coordinated release of the GNUstep core >> components. In the meantime a lot has happened. Base was completely >> rewritten, or so it seems from the outside and gui had to play catch up. >> Then I toyed around with the NIB loading and broke a few things. >> Now things are rather stable again and we should come back to our >> original plan. For gui this would be an intermediate release not the 1.0 >> release I am hoping to see later this year. >> What still needs to be done in gui is finishing the switch to #import, >> moving on to non fragile ivars will happen later. I first want to see >> the results base gets with its approach to that topic. >> >> Adam, could you once more take up the task of releasing GNUstep? We >> should give it another week or two so that people can complain about >> existing bugs that need to be fixed before the release. > > Well, just for a start: > > Rereading the Apple docs, I've noticed a (long-standing) incompatibility in > the nib loading code. When one of the nib loading functions is called with > an external name table and this dictionary contains the > NS(Nib)TopLevelObjects key, GNUstep passes ownership of the top-level > objects to the sender. However, this is not the case in Cocoa. Have a look > at the Cocoa Resource Programming Guide and in particular the section > "Loading Nib Files into Your Program Programmatically" > (http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW24). > Try the example code from Listing 2-4 with your favorite nib/gorm file and > you will observe a crash in GNUstep because the top-level objects are > released once too often. > > While testing this, I've also noticed that NSNib.h does not define the > string constants NSNibOwner and NSNibTopLevelObjects, which were introduced > together with NSNib in 10.3. Please note that Apple uses the values > @"NSOwner" and @"NSTopLevelObjects" for these constants for backward > compatibility. This is documented in Apple's NSNib.h header file, but I > couldn't find it in the online docs. I guess following Apple's approach > would simplify the nib loading code in a few places. > > Wolfgang > > > > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev