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: Wed, 17 Mar 2010 20:16:11 +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

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!
> 
> -- Doug Simons Principal Developer
> 
> 
> TestPlant Inc T    +1 720-890-0211 ext 13 4730 Walnut Street  F    +1
> 720-890-0209 Boulder, CO 80301        address@hidden USA 
> http://www.testplant.com This email and any attachments may contain
> privileged / confidential information. If you have received this
> email in error or believe that you are not the intended recipient,
> please delete all content and attached files and contact TestPlant
> via the switchboard on +1 720-890-0211 or via return e-mail. You
> should not copy, forward or use any part of the contents in any way.
> Any such unauthorised use or disclosure may be unlawful.
> 
> On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote:
> 
>> Am 13.03.2010 00:31, schrieb Wolfgang Lux:
>>> Fred Kiefer wrote:
>>> 
>>>> Thank you for looking into this. Looks like the basic
>>>> difference between Cocoa and us is in the window, window
>>>> controller and document interaction. And you are the sole
>>>> expert we have on this :-)
>>> 
>>> At the end of the day it looks like my expertise isn't needed
>>> here. The problem rather seems to be a space leak in the nib
>>> loading code, which seems to retain the owner of the nib file. To
>>> make testing a bit simpler I've attached a hopefully faithful
>>> translation of Ink's Document.gorm into a nib file with Apple's
>>> InterfaceBuilder. When I use that nib file instead of
>>> Document.gorm, Ink does not release the document when its window
>>> is closed. The window itself and its window controller are 
>>> released correctly.
>> 
>> Thank you for looking into this: I will try to resolve this issue.
>> I remember scattering FIXME's in the NIB loading code some time
>> ago. One of them might come in helpful now.
>> 
>>>> I think it is now save to replace the NIB outlet connector
>>>> code. I just checked the old code against the new runtime
>>>> functions of base and as far as I can tell the old code would
>>>> still work. We could just revert my change.
>>> 
>>> Please do so.
>> 
>> Done :-)




reply via email to

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