Re: install_name for libraries and frameworks on OS X
1) Update configure.ac in gnustep-make so it prints a warning if the user is on darwin and uses a filesystem layout other than 'apple'. This warning will tell the user they need to either set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH in their shell's environment as well as in ~/.MacOSX/environment.plist, or they need to install libraries and frameworks with an absolute install name (see below). It looks good Maybe you could make the warning specific to using the 'apple-apple-apple' library-combo (ie, building using the Apple frameworks). If you are using the 'gnu-gnu-gnu' library-combo, then the right thing to do might be to source GNUstep.sh in your shell ? 2) Add an option to make to use an absolute install name when linking the library or framework. I tend to like the single word options to make. Would you be opposed to me simply calling the option 'absolute'? The end user could then simply type make absolute=yes when building the library or framework. It looks good. I had a look around and I realized that most platform options we have at the moment are set at configure time though. Would that make things easier ? We could also use a longer expressive name there (you have to type it only once), ie ./configure --enable-absolute-install-paths that could set a variable (ABSOLUTE_INSTALL_PATHS = YES/NO) in config.make. The same variable could then be overridden on the command-line (as in, make ABSOLUTE_INSTALL_PATHS=NO) if needed for a special occasion, but I'd expect that most people will consistently either use the option, or not use it, so they'd set it once in ./configure and be happy. How does this sound ? :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSWindow NSGraphicsContext issue
Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The source of the problem is that when an NSWindow gets displayed it generates an NSGraphicsContext (or rather a subclass) which will then manage all the actual drawing. The window retain the context and the context has an info dictionary which includes the window. That way we already start off with a circular reference. To break this I released the window once, to adjust the retain count. Now when the window gets deallocated I first do a retain on it and then release the graphics context which will in turn result in a release on the window. Or so I hoped. There were a few issues with my original code. The graphics context and the dictionary where autorelease objects, so I had to postpone the deallocation of the window by returning from dealloc and let it be called again. This also needed a bit of isa sizzling as subclasses will not be aware of that reference counting trick and wont be prepared to get dealloc called twice. (And the code in NSWindow dealloc needed to be reentrant as well) With that all resolved I expected my code now to work correctly, but this still isn't the case. As it turns out, calling retain on an object that already was about to get released wont have the expected result. When a release is send to an object with a retain count of 1, that count wont be changed! Now this means that I have to differentiate between calls to _termianteWindow that come from dealloc, where I don't call the retain and calls for oneShot windows, where I need to increase the retain count before freeing the context. All of this now looks like an even bigger mess then the one I started with and now any help on how to clearly solve this would be welcome. Cheers, Fred PS: Some of the code I talk about above is still not committed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
Fred Kiefer fredkiefer at gmx.de writes: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The window in the dictionary is (should be) only used when creating the context : delete the dictionary after use or remove the window from the ddictionary. You might keep the window (if needed) in a non retained ivar : no cycle! Too simple...? Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
I was able to resolve most of the problems I listed below by not using autorelease objects. There still is one issue and it is an important one. When creating an NSWindow from a Gorm file the initialization is called twice. This will result in two backend objects being created for the window and one of them would leak and the window map would stay in an inconsistent state, after the window is freed. I was able to hack around this, by adding a check for an already existing _windowNum into initWithContentRect:styleMask:backing:defer:screen:. This only prevents part of the problem and a real fix would be not to have an NSWindow (or a subclass) in a Gorm file at all. For NIB files we already us NSWindowTemplate instead of GSWindowTemplate and this prevents the problem. Could somebody with a deeper understanding of Gorm please look into this issue? Fred Fred Kiefer wrote: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The source of the problem is that when an NSWindow gets displayed it generates an NSGraphicsContext (or rather a subclass) which will then manage all the actual drawing. The window retain the context and the context has an info dictionary which includes the window. That way we already start off with a circular reference. To break this I released the window once, to adjust the retain count. Now when the window gets deallocated I first do a retain on it and then release the graphics context which will in turn result in a release on the window. Or so I hoped. There were a few issues with my original code. The graphics context and the dictionary where autorelease objects, so I had to postpone the deallocation of the window by returning from dealloc and let it be called again. This also needed a bit of isa sizzling as subclasses will not be aware of that reference counting trick and wont be prepared to get dealloc called twice. (And the code in NSWindow dealloc needed to be reentrant as well) With that all resolved I expected my code now to work correctly, but this still isn't the case. As it turns out, calling retain on an object that already was about to get released wont have the expected result. When a release is send to an object with a retain count of 1, that count wont be changed! Now this means that I have to differentiate between calls to _termianteWindow that come from dealloc, where I don't call the retain and calls for oneShot windows, where I need to increase the retain count before freeing the context. All of this now looks like an even bigger mess then the one I started with and now any help on how to clearly solve this would be welcome. Cheers, Fred PS: Some of the code I talk about above is still not committed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
