[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
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
formalization whatsoever. You may think I'm being needlesly pedantic,
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
for the better. Some of the API additions were made by people who
did not understand how AppKit was designed at the time the additions
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.
has a policy of keeping compatibility with existing Cocoa classes,
that means breaking OpenStep compatibilty *IN THOSE INSTANCES ONLY*,
assuming those changes are sane. If GNUstep goes into "Cocoa Clone"
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
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.
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
GNUstep itself. GNUstep isn't beholden to Apple, nor should it be.
PortabilityKit doesn't make the kind of value-based decisions that
does. It's designed to just be a simple framework that you link
It is not a fork of GNUstep, it is complimenentary to GNUstep and will
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
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.
Defaults Manager - The premier editor for Mac OS X's User Defaults /
Re: Cocoa/Windows parallel dvlpmt, Tregaskis, Wade, 2004/02/04
Re: Cocoa/Windows parallel dvlpmt, Karl Kraft, 2004/02/04
Re: Cocoa/Windows parallel dvlpmt, Lars Sonchocky-Helldorf, 2004/02/04
Re: Cocoa/Windows parallel dvlpmt,
Dave Thorup <=