$(GNUSTEP_INSTANCE)_INTERFACE_VERSION is used in gnustep-make to define
the version of the shared object.
As a packager, there might be various reasons to
override the $(GNUSTEP_INSTANCE)_INTERFACE_VERSION
in order to control the library version.
So I do for gnustep-gui on OpenBSD packages. The problem here is, that
the libgnustep-gui_INTERFACE_VERSION is additionally used to specify the path
where resources like Panels, Localizations etc. get installed, however,
in Source/NSApplication.m, the use of
GNUSTEP_GUI_MAJOR_VERSION.GNUSTEP_GUI_MINOR_VERSION
As long as the libgnustep-gui_INTERFACE_VERSION is not overridden with
some other value, everything is fine. However, as in my case, Applications
aren't able to find the Panels/Translations provided by -gui anymore.
Decided to just remove the definition of libgnustep-gui_INTERFACE_VERSION
in these three Makefiles, as it was only used once, and used the
GNUSTEP_GUI_MAJOR_VERSION.GNUSTEP_GUI_MINOR_VERSION directly.
Alternatively, libgnustep-gui_INTERFACE_VERSION in these Makefiles
could could have been renamed to avoid this conflict.
On Windows, there is an occasional sporadic failure of autorelease to work correctly. In particular, this seems to happen when autorelease is invoked on an object while a call stack is in the middle of draining an autorelease pool. So, for example, when dealloc is called on an NSTextContainer, it then calls setTextContainer: on the associated NSTextView, which in turn calls textContainers on the layoutManager, which returns an autoreleased array of NSTextContainers. This array is sometimes released and sometimes it isn't.
Wrapping the setTextContainer: in an autorelease pool, which will then drain at the end of the method, rather than relying on the main autorelease pool in the run loop (which is in the middle of being drained), appears to fix this problem. This adds a small amount of overhead, but also makes the memory usage a little more efficient, since anything autoretained during the course of this method is released more quickly.
ToolTips can be present even when the flag is false, and it does no harm to invoke removeTipsForView: even if there are none. So this fixes a memory leak without any downside.
