Re: Cocoa/Windows parallel dvlpmt

[Dave Thorup]

Taking this off-list so please CC me on any replies...

On Feb 4, 2004, at 7:20 PM, Alex Perez wrote:

> Let me clear a couple of things up...
> OpenStep was a written, *FORMAL* specification. You can find PDF's
> (or PostScript files) of it around the net. Cocoa is just an API. with 
> no
> formalization whatsoever. You may think I'm being needlesly pedantic, 
> but
> here's why this is actually an important distinction to make: Apple can
> (and has) changed their API in willy-nilly fashions, and in some case 
> not
> for the better. Some of the API additions were made by people who 
> clearly
> did not understand how AppKit was designed at the time the additions 
> were
> made. NSToolbar is a great example of this, since it's not Just Another
> View (it has hooks in NSWindow), which is probably what it should have
> been. The OpenStep specification was well-designed and as such was not
> intended to be changed or modified frequently. Apple's specification is
> not as static, and as such it can and does change every 18 months. 
> GNUstep
> has a policy of keeping compatibility with existing Cocoa classes, 
> even if
> that means breaking OpenStep compatibilty *IN THOSE INSTANCES ONLY*,
> assuming those changes are sane. If GNUstep goes into "Cocoa Clone" 
> mode,
> it will forever be playing catch up, since Apple plays popularity games
> because they are a corporate entity. Also, some of their class
> implementations are notably half-assed...(NSXMLParser) Others are a 
> great
> idea (NSNib, which will be implemented shortly in GNUstep).

I understand this, however, speaking from the perspective of a Cocoa 
developer, Cocoa compatibility is what is important.  In order to 
attract more Cocoa developers (marketing) to the project, then a 
mission objective needs to be Cocoa compatibility (even if it is always 
playing catch up).  I like your idea in this regard (more below).  Old 
NeXT and OpenStep developers may like the design goals of the GNUStep 
project better, but Cocoa developers are going to want Cocoa 
compatibility first and foremost.

Going back to the WINE analogy, their goal is "bug-for-bug" 
compatibility with Windows.  Win32 is also a moving spec. and WINE is 
always playing catch up, but that doesn't stop them, nor change their 
goal.  Granted the purpose of the WINE project is different from 
GNUStep, however one of their goals is to make it so a Win32 
application can be recompiled using WineLib without any major source 
changes.  If this would be the case (or the goal) for GNUStep, i.e. you 
could just recompile a Cocoa app and it would just work on GNUStep for 
Windows or Linux, then I believe that you would attract a lot more 
Cocoa developers to the project.

> 100% Cocoa compatibility will *NEVER* be achieved in GNUstep itself. 
> Some
> things are way too apple-specific...NSAppleScript, etc. I have begun a
> project called PortabilityKit which aims to implement some of the, er,
> well, more poorly-designed Apple classes that will likely never get 
> into
> GNUstep itself. GNUstep isn't beholden to Apple, nor should it be.
>
> PortabilityKit doesn't make the kind of value-based decisions that 
> GNUstep
> does. It's designed to just be a simple framework that you link 
> against.
> It is not a fork of GNUstep, it is complimenentary to GNUstep and will 
> not
> function without it. It is currently in the very early stages, and if
> anyone is interested in helping, let me know. It is not an official GNU
> project, does not require copyright assignment, and will be released
> under the LGPL.

This sounds like a great idea and something that, IMHO, needs to be 
done.  If the GNUStep project as a whole will not try to clone Cocoa, 
then there needs to be a project that does (minus stuff like 
NSAppleScript).  Even if it's constantly playing catch up it still 
needs to exist.  I would think a good goal for such a project would be 
to follow OS X releases, i.e. probably a first goal would be Jaguar 
compatibility, then Panther, etc.

As for myself I would love to work on the Windows port of the GNUStep 
project.  Every time I think about having an easy porting path from 
Cocoa to Windows I think of the enormous opportunities there would be 
for the Mac community.

The problems for me are these:  1) Time - working full time and being 
married I get next to nothing in spare time to work on any such 
project.  2) Lack of Windows experience - I have close to zero 
experience developing on the Windows platform (outside of Java), I 
don't even own a PC.  Though I'd love to help out, I'm just not a 
Windows programmer.

The GNUStep project is one that I am a fan of and I'd really like to 
see succeed and mature.  I only wish I had the time and experience to 
help it go where I want it to.
_____________________________

Dave Thorup
Software Engineer
dave@kuwan.net

http://www.kuwan.net
Defaults Manager - The premier editor for Mac OS X's User Defaults / 
Preferences database.