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
<[EMAIL PROTECTED]> 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..
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
