Re: [RFC/Proposal] Cocoa.h header

[Alex Perez]

Nicolas Roard wrote:
> Le 21 nov. 04, à 01:51, Alex Perez a écrit :
>
> > Currently, GNUstep-GUI has a file in Headers/Cocoa/Cocoa.h which is 
> > not installed by default. I would like to change that, because there's 
> > no reason for it not to be installed, and I have a use/need for it. 
> > However, the header is not a direct analog to the Apple's Cocoa.h. 
> > This is bad. I propose the following:
> >
> > Our Cocoa.h needs to be exactly the same as Apple's. All Apple's does 
> > is #import <Foundation/Foundation.h> and #import <AppKit/AppKit.h> and 
> > *THAT'S IT*. Right now, there's other darwin-compatibility stuff in 
> > there which should be elsewhere. I propose that stuff be moved to 
> > Headers/Cocoa/CocoaCompat.h or something similar. Cocoa.h will not 
> > #import this file by default, it will be like most of the other 
> > compatibility headers which are distributed with GNUstep; You will 
> > need to know that you need to import it explicitly.
> >
> > Both of these files would then be installed when make install is run 
> > for -GUI.
> >
> > Please, contribute your feedback. If you are against such an action, 
> > please explain why and what you propose instead.
>
>
> Installing Cocoa.h by default is probably a good thing (possibly not 
> installable by a configure flag), but I don't understand why we 
> shouldn't put the compatibility stuff in it ?

Because I've yet to see an OS X app yet that needed any of them to 
actually work/compile. I am all for keeping the *CONTENTS* of the file 
in a more reasonable header. Our Cocoa.h needs to be functionally 
equivalent to Apple's Cocoa.h, and right now it is not, there's a bunch 
of extra cruft in there which dosen't belong *IN COCOA.H*. It belongs 
somewhere more appropriate. As I said, the extra stuff in there is not 
Cocoa compatibility stuff, it's Darwin/OS compatibility stuff, and it 
should not be where it is currently.

> Cocoa.h isn't used by gnustep programs, but by OSX programs; it make 
> sense to add what's needed to help compile OSX programs on GNUstep in it.
> I don't see much the point of putting a CocoaCompat.h -- it means that 
> when you want to compile Cocoa program you will either need to include
> CocoaCompat.h everywhere, or modify Cocoa.h to include it, which kinda 
> defeat the point of having a Cocoa.h already installed..

Would you put stuff to do with NSTableView in an NSObject header? No, 
because it doesn't belong there. There's a more appropriate place for 
it, and that's where it should be. I reiterate, I am in no way opposed 
to the "cocoa" (sic) compatibility stuff, but I *AM* opposed to it being 
in Cocoa.h.

As I said in my previous mail, I've yet to come across a cocoa app which 
needs any of the extra cruft in our Cocoa.h (I use my own which ONLY 
includes AppKit.h and Foundation.h and nothing else, just as Apple's 
does) and as such I do not think it belongs there, because the potential 
for the extra stuff to cause problems is greater than the potential benefit.

For the record, last I checked, Alexander Malmberg agreed that Cocoa.h 
should not have all this extra cruft as well. Alex, I'd appreciate it if 
you'd weigh in on this matter here. The same goes for you, Fred, since 
you're the one who put the stuff into the header in the first place.

Cheers,
Alex Perez