Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Alex Perez <email@hidden>
- Date: Wed, 4 Feb 2004 16:20:34 -0800 (PST)
On Wed, 4 Feb 2004, Dave Thorup wrote:
>
I think Florent makes some great points here, and here's my opinion...
>
>
On Feb 4, 2004, at 11:02 AM, Florent Pillet wrote:
>
>
> Now there are a few things about GS that need to be very clear:
>
>
>
> - NeXT having been absorbed by Apple (though some will say that it
>
> happened the other way round :-)), the new baseline OpenStep APIs are
>
> Cocoa. Any attempt to ignore this fact will lead to Cocoa developers
>
> turning away from GNUStep. Let me repeat that: OpenStep is history.
>
> Cocoa is the new specification. Hence, GS should at least provide the
>
> equivalence to the N-1 version of Cococa (ie currently offer the set
>
> of APIs that were in Jaguar would be deemed acceptable by developers).
>
>
The importance of this cannot be overstated. GS really needs to make
>
it a #1 priority to maintain 100% compatibility with the new OpenStep
>
which is Cocoa. If this goal does not become one of the top priorities
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).
>
of the GNUStep project, then the majority of Cocoa developers will
>
never look into it seriously, nor will they contribute to it.
>
For example, what if the WINE project decided that they wanted to implement
>
some of Microsoft's Windows APIs differently, or not at all. Sure,
>
their implementation could be "better," but if it were different and
>
didn't behave the same way then it would lose its appeal.
>
>
> - I think that the look and feel issue needn't to be overlooked. As
>
> Alex mentioned it, people must overcome their own personal taste and
>
> realize that in any given platform, the only acceptable way of
>
> displaying the UI is by respecting the platform look and feel.
>
>
This is also a hugely important priority. In order to appeal to Cocoa
>
developers, GNUStep will need to make their AppKit implementation use
>
native Windows controls or at least controls that look exactly like
>
native controls. If this is not a priority of the project then Cocoa
>
developers won't be interested in using or contributing to the GS
>
AppKit.
Stability first, then theming.
>
>
In reading the GNUStep mission I see that maintaining Cocoa
>
compatibility is there, but does not look like a huge priority. That
>
may be fine for the GNUStep project as it is now, but in order to
>
attract more developers the mission should be changed to strive for
>
Cocoa compatibility. I think Florent's suggestion of N-1 version
>
compatibility is acceptable (N-2 wouldn't be too bad). Remember this
>
is marketing. In order to attract more Cocoa developers, the goal of
>
100% (or 99%) Cocoa compatibility needs to exist.
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.
Alex Perez
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.