[Top][All Lists]

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

Re: Portability/Compatability between GNUstep <---> Cocoa...

From: thisguyisi
Subject: Re: Portability/Compatability between GNUstep <---> Cocoa...
Date: Mon, 12 Jan 2004 00:08:56 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3

Nicola Pero wrote:
It's easy to make everyone happy with stuff like NSToolBar.  We put an
implementation in gnustep-gui.  If you are an OpenStep purist and don't
want to use it, you don't use it - you can ignore it.  If you are an
Apple-compatible guy and want to use it, you use it.  I don't see why 
should remove NSToolBar from gnustep-gui.  The problem arises when 
Apple compatibility pollutes or confuses the original OpenStep classes
(then, we need a "superior workaround").  Adding an additional separate
class does not.
I know at least one core developer who will likely fight the inclusion 
of NSToolbar. Many think Apple's Toolbar implementation sucks.

In my experience, things tend not to work very well when we are "fighting"
between each other. :-)

Both points of view have their reasons.

In this case to me it looks like if we add NSToolbar and write clearly in
the documentation that it's there just/mainly for compatibility with the
current Apple system (maybe we document it in a different section, outside
the main listing of classes, in an Apple compatibility area), the solution
should make everyone happy and I don't see any reason to "fight".

The mission statement of GNUstep.org indicates things that are sane Cocoa additions to the OpenStep spec will be included in GNUstep (the API).

Perhaps GNUstep should be structured in 3 distinct chunks. Internally @ the core the OpenStep compliant code, aka "OpenStep canon." A second chunk of code would be the GNUstep-extensions layer (GNUstep's extensions to the OpenStep spec). Thirdly a Cocoa computability layer (e.g. Portability Kit) where all of Cocoa's extensions to the OpenStep spec could "live".

Maybe this is how it is set-up/designed already, or perhaps the extensions that have been deemed "good" are interspersed/intermingled with GNUstep's OpenStep compatible code.

I know there are flags to enable/disable various levels of compatibility between strict OpenStep-compatible code, and Cocoa-compatible code.

How exactly is GNUstep designed at the moment?

Best Regards,

reply via email to

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