gnustep-dev
[Top][All Lists]
Advanced

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

Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m


From: Fred Kiefer
Subject: Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Date: Fri, 19 Mar 2010 09:20:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3

Great that you could work around the issue. It still remains to be
solved in a general way. It surely helps to know how your problem was
triggered. Did your controller retain the objects from the second NIB
file? And then when the controller was released these objects also
disappeared?
My current position on NIB loading is that no magic should happen there.
Objects created while loading a NIB file should follow the standard
rules. Nothing will be retained except for the top level objects being
retained in the top level object array. (And of course instantiated and
visible windows by the normal window display mechanism)
That way anything that is not retained by the owner or specifically
extracted from the top level object array will be freed after loading
the NIB file when no other reference exists.
If we can all agree on this position (and better yet, check that it is
valid on Cocoa), I am going to change our code into this direction.
This may require some extra handling in NSWindowController or NSDocument.

Fred

Am 18.03.2010 22:49, schrieb Doug Simons:
> Okay, we've resolved this issue in our code at this point. We had a
> situation where a controller object was being instantiated within our
> MainMenu.nib. When that controller's init method was called it was
> loading another nib, and it was an object in that nib (or maybe lots
> of them, who knows?) that was being freed before we could retain it
> in our applicationDidFinishLaunching: method in the controller.
> 
> We removed the controller instance from the MainMenu.nib and are
> instantiating it separately in code (which is probably better anyway)
> and are no longer crashing.
> 
> Doug Simons
> 
> P.S. No stupid company disclaimer this time -- I'll try to remember
> to delete it in the future. :-)
> 
> On Mar 18, 2010, at 2:24 AM, Fred Kiefer wrote:
> 
>> Just in case my last mail wasn't clear enough on that point: All
>> you have to do to get your application working again with the
>> current NIB loading code is to add a setter method that retains its
>> argument. And for us it would be important to have an example of
>> how it is failing without that setter.
>> 
>> Fred
>> 
>> Am 17.03.2010 20:16, schrieb Fred Kiefer:
>>> I don't expect to see much differences between Windows and X11 on
>>> NIB loading. If you could provide me with an stripped down
>>> example I would try to have a look at what goes wrong there.
>>> 
>>> I'm already investigating an issue with the new code when loading
>>> a NIB file that Wolfgang prepared for Ink. But there things seem
>>> to be the other way around. Object are retained while loading
>>> that shouldn't be.
>>> 
>>> What you cannot expect in the short run is a revert of this code.
>>> If we start that there will be no stopping. The intermediate code
>>> was proven wrong and it had issues for Wolfgang. Now the new
>>> code, which is the old one, should be correct as far as we know,
>>> but it may uncover issues with NIB loading that had been
>>> previously hidden. I think it is better to track this issues
>>> down. Hiding issues wont help. Take a look at the hack Greg added
>>> some time ago into NSClipView to have it retain the cursor twice
>>> when loading it from a NIB file. This was not only wrong, it
>>> also hid the fact that the NSCursor un-archiving was broken.
>>> 
>>> I am really willing to help you here, but for that I will need
>>> some code to work with that clearly shows this problem (and is
>>> proven to work on Apple).
>>> 
>>> Fred
>>> 
>>> PS: Have we talked about your stupid disclaimer before? Is there
>>> a way to turn it off when sending mails to this mailing list?
>>> 
>>> 
>>> Am 17.03.2010 18:19, schrieb Doug Simons:
>>>> Unfortunately, this change (Fred's commit in r29223) has broken
>>>> our ported Cocoa application (at least on Windows -- haven't
>>>> had time to check on Linux yet). At least some objects in our
>>>> nib files are now freed after the nib loads, and our
>>>> application crashes when trying to access them. Reverting
>>>> NSBundleAdditions.m to the version prior to r29223 fixes the
>>>> problem for us.
>>>> 
>>>> We would appreciate if this change could be backed out until
>>>> this problem can be resolved. I don't understand everything
>>>> that's going on during nib loading well enough to  attempt to
>>>> solve this myself. Thanks!





reply via email to

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