Re: OpenOffice.org on OS X and GNUstep

[Adrian Robert]

On Nov 3, 2005, at 3:03 PM, Lars Sonchocky-Helldorf wrote:

> Am Donnerstag, 03.11.05 um 15:32 Uhr schrieb Adrian Robert:
>
>
> > On Nov 2, 2005, at 3:17 PM, Sean Fulton wrote:
> >
> >
> > > On 2005-10-07 10:23:07 -0400, Adrian Robert  
> > > <arobert@cogsci.ucsd.edu> said:
> > >
> > >
> > > If they're paying attention at all they won't even consider  
> > > Carbon. I believe Apple has essentially told developers that  
> > > Carbon is dead. If you want your app to run (well) on OS X on  
> > > Intel, you have to develop with Cocoa. Porting something to  
> > > Carbon now would be a waste of time.
> >
> > That's good news if so, but if the story so far is any indication,  
> > Carbon will continue to maintain a very vigorous life of its own,  
> > regardless of what Apple wants.  Microsoft, Adobe, and others  
> > won't rewrite their apps, and even Apple would have a lot of work  
> > to do, redoing Finder, iTunes, etc..  (I have NO idea why they  
> > essentally *rewrote* Workspace Manager in Carbon in the first  
> > place, but there you have it..)
>
> They did not rewrite Workspace Manager in Carbon they killed it and  
> ported stuff from the existing Mac OS 9 Finder to Carbon, partially  
> to prove that Carbon was a viable way to do such things since the  
> major companies like Adobe and Quark were not convinced and thought  
> about dropping Mac support at all. Even the sheer existence of that  
> thing called Carbon is a result of this. OPENSTEP was ported to PPC  
> and somewhat ready (called Rhapsody) but the application suppliers  
> did not jump on that train - basically to avoid having their apps  
> rewritten in ObjC/OpenStep.

It's an interesting question *why* the app developers felt this way,  
given the maintainability advantages of OpenStep, and the fact that  
Adobe, Quark, and others were _already running and selling their  
software on OpenStep_ pretty much right up until the beginning of the  
Rhapsody era.  My guess is that the OO nature of the API made it  
architecturally more difficult to share common code with the Windows  
versions.  E.g., in Emacs, the cross-platform GUI works by having a  
really micro-managing shared core that doles out mini-tasks to the  
windowing code (which in turn passes individual low-level events  
back).  This runs contrary to the OO approach of semi-autonomous  
components maintaining and updating their own state, so that the  
Cocoa/GNUstep port ends up using lots of low-level function calls and  
not benefitting from NSText or other subsystems the way it should.

OO.org, if they go forward with Cocoa, will probably face these same  
problems, and thus not end up singing its praises as one might think  
they would..