[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa/Windows parallel dvlpmt

From: Dave Thorup
Subject: Re: Cocoa/Windows parallel dvlpmt
Date: Wed, 4 Feb 2004 21:42:15 -0500

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

Defaults Manager - The premier editor for Mac OS X's User Defaults / Preferences database.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]