Re: Antwort: Re: import vs include Re: Porting autogsdoc to OSX

[Pascal Bourguignon]

> From: =?ISO-8859-1?Q?Marcus_M=FCller?= <znek@mulle-kybernetik.com>
> Date: Wed, 27 Feb 2002 19:52:15 +0100
> 
> 
> On Wednesday, February 27, 2002, at 06:14 PM, David.Ayers@brainag.com 
> wrote:
> > The real question seems to be, does it make any sense to invest so much
> > work into seprating this code into a seperate library/bundle, just so 
> > that
> > GNUStep apps can be ported to Cocoa easily? Or does it suffice to have 
> > base
> > compiled under OS X? I must say I haven't formed an opinion yet, but I'm
> > also sure the implecations reach very far. It wouldn't just be matter of
> > base, but would imply any framework/library which clones a Cocoa API 
> > must
> > be devided in a pure API library and extension library.
> >
> > In effect:
> > base    - would implement OPENSTEP and Apples (current) API
> > baseExt - would implement all other things
> >         - would need to compile with base & OS X/Foundation [Headers] 
> > (ie
> > [...]
> 
> Yes, an answer to these questions was exactly what I was looking for in 
> my initial post. Actually I was aware of the resource constraints, so I 
> asked if people think that development time should be spent on this 
> issue. What followed, in my opinion, was a sometimes heated debate over 
> the goals of GNUstep and prioritization of that goals. Nevertheless I 
> found it very constructive, although my initial questions haven't been 
> answered yet.
> 
> There seem to be two major interest groups:
> 
> 1) OS X developers who want to "embrace GNUstep" and port their Apps to 
> GNUstep - but who also want to take some functionality from GNUstep and 
> put it to use on OS X.
> 2) GNUstep developers who want to extend GNUstep and build applications 
> using GNUstep, without necessity of porting them to other "OpenStep 
> compliant" systems.

Please don't forget the third group:

  3) GNUstep developers  who want to build  applications using GNUstep
     (for  the nice user  interface look)  AND to  port them  to other
     "OpenStep compliant" systems such as MacOSX (for the customers).

For this group, GNUstep extensions are a trap unless they're ported to
MacOSX (hence in a separate framework there).

> Technically the proposal you make in your above statement would suit the 
> needs of group 1), whereas group 2) would not necessarily benefit of it. 
> As a matter of fact, group 2) would rather like to avoid that as it 
> could certainly break things currently working during the migration.
> 
> > But the AppOSXGNUStepCore.app will not be able to DO to other Cocoa 
> > apps!
> > It couldn't even Cut&Paste and Drag&Drop to other Cocoa apps! Does this
> > alone mean that GNUStep apps must use Cocoa to be integrated with other
> > Cocoa apps on OS X? Here I recall the was discussion a while back when
> > talking about X integration and the Pasteboard! (Wow, I think this is 
> > the
> > showstopper and I formed my opinion. We should divide the libraries and 
> > be
> > able to compile CORE-Extensions agains Cocoa frameworks.)
> 
> I wouldn't go that far. During the years I've become more pragmatic. 
> Although DO is a very cool technology to have, there's a surprisingly 
> small number of applications depending on it. Some time ago I'd liked to 
> have DO between GNUstep and OS X, but because of a natural lack in that 
> respect I had to reconsider my design. I'm very happy using XML-RPC now 
> (and able to interface with a lot more clients btw.).
> 
> Cheers,
> 
>    Marcus




-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------