I think we waited now long enough to be sure there wont be any big surprises when we make a new release. There still are important open issues, but as far as I can see no regressions. I will be away for the next week, perhaps this is the perfect time for a release. When I come back I will have plenty of time for fixes.
Cheers Fred Gregory Casamento wrote: > I agree that we should delay the release of gui since there have been > a number of changes that have not been fully tested. While I'm sure > that they are working I have tested them with a limited set of apps > and would like to see a greater degree of testing done prior to an > official release. > > The change to NSSplitView is based on the idea that the subviews of > the splitview should always resize themselves since this appears to be > the observed behavior on Cocoa. I need to do further testing on this, > so I left it in the nib loading code for now. > > Regarding inconsistencies between loading from a nib and creating in > code, I'm not sure that the assumption that they should always be the > same is entirely valid. > > GC > > On 4/15/09, Fred Kiefer <fredkie...@gmx.de> wrote: >> What ever numbering system you prefer :-) >> To me it is just the same and people will always find a reason to >> complain about it. >> >> For gui I would like to delay a new release for a few weeks. Gregory has >> done a load of changes which will need some testing. And one set of them >> (The changes for autoresize on NSView and subviews) surely is a work >> around for some kind of problem. I am still trying to figure out from >> the changes what the underlying problem might be. Most of the changes >> have been reverted, but the remaining on on NSSplitView leads to an >> inconsistency between objects loaded from a NIB file and ones created in >> code. This is not what we want, but Greg surely had a good reason for >> this change. If only he would tell us... >> >> >> I am also currently looking into a problem with NIB loading, which might >> even be related to Gregs issue. The NIB file for the SimpleWebKit >> Browser gives different results for the autoresizes subviews ivar on >> Cocoa and GNUstep. This code uses a binary NIB file >> devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib >> >> When converting this NIB file to XML (with a simple tool I have written >> that just uses to calls on NSPropertyList) I end up with an entry >> >> <key>NSvFlags</key> >> <false/> >> >> This looks completely wrong to me, but perhaps somebody with more >> understanding of keyed coding could explain this? >> >> After these two issues have been resolved a new release would be fine >> from my point of view. >> >> Fred >> >> PS: I will be away for the next ten days, so don't expect something quick. >> >> Adam Fedor wrote: >>> It's been a long time now (LTN) since our last release, perhaps we >>> should do a new one soon? Also, in an effort to please everyone >>> (ETPE), I was thinking we should separate the release numbering from the >>> SO version numbering, at least on the unstable branch as long as there >>> are no ABI changes. This should be really easy as we just need to define >>> >>> INTERFACE_VERSION >>> >>> in the top-level makefile. So >>> >>> Base/Gui unstable release: >>> Subminor release (1.19.X) - bug fixes or API changes >>> increase subminor version >>> interface version does not change >>> Minor release (1.X.0) - API changes and bug fixes >>> increase minor version >>> interface version does not change >>> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >>> increase version >>> increase interface version to match. >>> >>> Base/Gui stable release: >>> Subminor release (1.18.X) - bug fixes only >>> increase subminor version >>> interface version does not change >>> Minor release (1.X.0) - ABI, API changes and bug fixes >>> increase minor version >>> interface version changes to match >>> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >>> increase version >>> increase interface version to match. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev