Re: Next release

[Fred Kiefer]

I would love to see a GUI release 1.0, but clearly this is something we
wont manage in the next few months. This leave your first two options.

There is one fundamental difference between gui classes and base
classes. Most of the Foundation classes encapsulate a clear well defined
concept that wont change over time, whereas Apple keeps on extending the
AppKit classes to include more and more features. For that reason the
approach to have a few dummy ivars will only work for a limited amount
of time or for just a few classes.

For the more flexible classes I would expect that the pointer to some
separately allocated memory is the only option that is worth
considering. Here we have different possibilities. For something like
the NSClass hierarchy either each class could have its own extension
pointer and in the end its own extra memory. Or we implement a basic
mechanism for that once in NSClass and only require additional space in
each subclass. That way we would only need on additional malloc/free
call, on one per subclass.

There are more details that need to be sorted out, but this is clearly
the way to go.

Cheers,
Fred

Gregory John Casamento wrote:
> Adam/Fred,
> 
> One of the things I think we need to do in order to address the ABI
> compatibility issue is to adopt a strategy similar to what Apple has
> done in it's headers.
> 
> Currently there is a lot of space which is marked as "reserved" in
> Apple's header files.   This allows for future additions without
> changing the memory layout of the class which is what leads to ABI
> issues and subsequently the need for recompilation.  This would allow
> older versions of applications to continue to function with newer
> versions of the core libraries even after a modification where some
> of the "reserved" space has been consumed.   The trick is to reserve
> just the right amount of space so that you don't make your classes
> needlessly big and so that you adequately anticipate the future
> growth of some.
> 
> Another potential solution to this problem, a bit different from the
> one above and probably a little risky is to simply have a void
> pointer in each class' ivar section and have it point to the
> appropriate structure when initialized during runtime.   This would
> allow the ABI to be stable since the class' foot print would always
> be the size of the void pointer.   The structure could then be
> changed to our hearts content without need to worry about ABI
> compatibility issues at all.  The drawback to this one is that it's a
> major undertaking to implement it and, it's, potentially hazardous.
> 
> The third option is to get gui to a point where it's ABI is actually
> stable.  Consider that base hasn't changed much for a long time.
> This is because it's been at 1.0 for a very long time and because it
> is truly stable.
> 
> There are a myriad of things we need to focus on in gui at this point
> before we can, rightfully, call it a 1.0 release.   Printing is the
> one thing that I think is most prominent on my mind regarding gui at
> this point.   Printing is incomplete.   Last time I started up
> TextEdit.app or Ink.app and typed and tried to print a page, it came
> out blank.   This could be a configuration issue, or it could be
> something else, I don't know.. if it is, please tell me. :)
> 
> Anyway... I'll come back later and we can discuss what gui 1.0 should
> be. :)
> 
> Later, GJC
> 
> Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief
> Maintainer
> 
> ----- Original Message ---- From: Fred Kiefer <address@hidden> To:
> Adam Fedor <address@hidden> Cc: Developer GNUstep
> <address@hidden> Sent: Tuesday, March 4, 2008 1:37:49 PM 
> Subject: Re: Next release
> 
> Adam Fedor wrote:
>> On Mar 3, 2008, at 1:40 PM, Riccardo wrote:
>> 
>>> A newer stable release should be done indeed. Adam?
>>> 
>> That's up to Gregory, et. al.  Do we have any goals for the next
>> stable release? gui 1.0?
>> 
> 
> I am still a bit reluctant to use the version number 1.0. We would be
>  committing us to stay ABI compatible from then on and we are not
> ready for that. Using the number 0.14.0 would be fine for me.
> 
> (I already have a proposal for ABI stability, I just need time to
> write it up and then find somebody to implement it :-)
> 
> Fred
> 
> 
> _______________________________________________ Gnustep-dev mailing
> list address@hidden 
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
>