[dfiler]

Originally posted by rmendis:
1. The NEXTSTEP/Rhapsody Workspace Manager was very extensible. It had support for DOS, Mac (HFS), UFS (native), NFS and even NetWare filesystems. Adding HFS+ to that wouldn't have required a re-write.

I see now. Most of my experience was with actual NeXT hardware, machines without local HFS volumes.

Now I too am wondering about the criteria considered by Apple while selecting a framework/API for the OS X finder. When Apple acquired NeXT they gained at least a few Obj-C and Cocoa developers. I wonder which groups these developers were assigned to and if internal politics played much of a roll. Perhaps these developers were tasked with bringing AppKit and FoundationKit back up to speed while the existing (carbon) finder team continued to work on the finder.

Apple has a finite number of developers. There may not have been enough Cocoa developers to go around. Does this sound like a plausible scenario?

Someday, I'm sure an ex-employee will write a fascinating book on the NeXt takeover of Apple. Maybe it will be Steve.

[Amorph]

Originally posted by bewebste:
This is not the case, actually, Cocoa methods are fairly commonly layered on top of Carbon functions, not the other way around. NSTextView uses ATSUI for measurement/layout, NSMenu sits on top of Carbon menus, etc.

It would be hardly less accurate to say that both are layered on top of CoreFoundation. In some cases, Carbon is "below" Cocoa, but in others they're just two different views of the same underlying, er, foundation.

Some projects within Apple have made the Toolbox->Carbon->Cocoa transition (the iMovie team, for example) and at least according to their presentation at the last WWDC the investment in time was less than they expected, and altogether worth it. Given that, a rewrite in Cocoa would not surprise me.

Apple used Carbon early on for mostly political reasons — see, we're eating our own dogfood! — as well as for OS 9 compatibility. Now that OS 9's dead, and Carbon is established, I can definitely see them moving to Cocoa wherever possible. If they're going to concentrate as heavily on software as they seem to be doing, they really need Cocoa's advantages.

[Millennium]

Originally posted by dfiler:
The finder has never been Cocoa. The NeXTSTEP workspace manager was cocoa but was written for a completely different file system and windowing system.

The Workspace Manager code was used in early versions of OSXServer (before OSX was released). It was even in development versions of OSX, up through DR2. It went away when Aqua was introduced.

It was easier to recycle the finder's code-base than it was to start from scratch with Cocoa.

Except that they didn't recycle the OS9 Finder's codebase. OSX's Finder was a total rewrite, even though it was Carbon.

I think the Finder should have stayed Cocoa, but not out of any Cocoa-zealotry or anything. I'm simply going from the standpoint that Apple had a perfectly good file manager already, which happened to be Cocoa, and there was no real reason to drop that. Yes, it was important for Apple to eat its own dogfood with Carbon, but the dogfood app should have been AppleWorks. Certainly there was still work to be done on the Finder even if they'd kept the Cocoa codebase, but it couldn't possibly have been nearly as much effort as totally rewriting it. The extra effort spent could then have instead gone to improving AppleWorks, leaving us with two great (or at least passable) apps, instead of 10.0's Finder (yuck) and the current AppleWorks (the original Bad Carbon Port).

However, the Finder is Carbon now, and it's beyond the point that the Cocoa Finder had been. I see no reason to rewrite it yet again; indeed, that would just take more extra effort that should be going to AppleWorks.

[iJed]

Originally posted by Phoenix1701:
Not to nitpick, but technically that's actually not true, and that point is one I think is worth bringing up to some of the non-developers here.

Here's a simple snippet of code:

Code:
int sum = 0;
for (int i = 0; i < 100; i++) {
    sum += i;
}

That piece of code is written in C. It is also written in Objective-C. It is also written in C++. It is also (I believe) written in C#. The point, which others have tried to raise but have perhaps abstracted out a bit, is that Cocoa and Carbon -- and, by extension, Objective-C and C++ -- are not different languages. They are, rather, different sets of libraries and frameworks built onto the same basic language, C.

Your example code wouldn't compile in a strict C compiler -- just try it in gcc -- because you declare a variable inline in the for loop.

Edit: This code wouldn't compile in Objective-C either BTW. After all its not C++ (or Java).

Also ObjC and C++ are different languages. Just because that syntax is accepted by them both doesn't mean that they are the same languages. That code would also compile without problem in Java and it would do the same thing. However Java and C are two very different languages. Imagine if they had written Cocoa in Java! :-)

[dfiler]

Originally posted by Millennium:
The Workspace Manager code was used in early versions of OSXServer (before OSX was released). It was even in development versions of OSX, up through DR2. It went away when Aqua was introduced.

Except that they didn't recycle the OS9 Finder's codebase. OSX's Finder was a total rewrite, even though it was Carbon.

Thanks!. This thread has amazingly become less zealous and more informative with each post. Is this still MacNN?


But seriously, I feel bad for contributing a bit of misinformation. I played with the DP releases but never had much experience with OSX server (the pre OS X consumer version). The rest of this post isn't meant to attack your position so much as to clarify the certainty of it.

If anyone has more details regarding the staffing of the Finder development team, I�m quite interested. The �Eat our own dogfood� phrase has almost become an urban legend. I vaguely remember this being reported on back with Rhapsody�s cancellation/OS X�s announcement. Did the phrase actually come from an Apple employee�s lips? Even if uttered by Jobs at the '98 WWDC, I'm inclined to believe that this might only be their public justification and that there could be other significant motivators.

Also, I�m curious about the source of your info about a �complete rewrite�. When I set out to do a complete rewrite, this generally means that I start with a blank file with a new name. Next, I prototype the appropriate functions and paste in as much of the old code as possible...

Finally, any thoughts on the �not enough cocoa developers to go around� theory?

[Toyin]

Interesting posts. I'm not a programmer and I don't get the finer details of what makes one program fast and another one slow. However, Apple's track record with cocoa apps (iphoto 1&2, ical 1 , imovie 3) makes me cringe at the thought of a cocoa finder. These apps have great GUIs and are easy to use but are just slow, slow, slow. (Dual 500 1.5gb of ram, 12" PB 640MB ram)

[BuonRotto]

I have no technical knowledge of this stuff, but I'll point out some things that I understood about why the Finder is Carbon:

1. I heard that it needed to be Carbon to interact with Classic, Classic files (sans extensions, with extra forks) and so forth.

2. I heard that they did re-use some code from the Classic Finder, stuff like the copy mechanism that does pre-flighting and so forth.

3. I do remember Jobs mentioning something about "eating our own dog food" in one keynote, might have been an old WWDC actually.

as for my impressions with theFinder, some of them are small UI quirks that any Carbon app would have but probably won't or shouldn't after Panther -- real sheets and toolbars, maybe drawers, etc. The other part is just the lack of good threading, processor time sharing (netowrk locks stuff up. The former is a Carbon issue, the latter probably isn't.

The reason I'd like to see a Cocoa Finder even now is for the more elegant UI currently evident in Cocoa apps IMO, or I should say the potential ease to make it in Cocoa, though I think this has as much to do with who is creating the UI more than what API it's being created with. Also, the whole Cocoa services, standarized panels, etc. thing would make users more aware of this stuff and they would begin to use them and the apps to their full potentiual if they had something like the Finder with this stuff already. I've answered more questions about "why doesn't OS X have xyz?" over the past 2 years when it really does have xyz, just that the Carbon app developers and the Finder don't support it. In general, while some of Apple's Cocoa apps are slow, most of the ones I use on a regular basis (such as SketchUp, TIFFany, or Create) are as fast as any of my Carbon apps, and are a much more pleasurable experience than any of the Carbon apps I've used. I feel like --and please forgive this is rather snooty attitude-- I know what the OS X user experience is more than most people who use ported OS 9 apps and wonder what the deal is.

Sorry, I know a lot of this stuff has already been covered, just my 2 cents...

[rmendis]

Originally posted by BuonRotto:
[B]1. I heard that it needed to be Carbon to interact with Classic, Classic files (sans extensions, with extra forks) and so forth.
B]

Not true.

NEXTSTEP 3 Workspace Manager had pretty complete HFS support built in and was a very extensible file system manager.

IMHO there was little or no reason to make a perfectly good and time tested Cocoa Workspace Manager into Carbon...unless at some point in time Apple had thought of back porting it to Mac OS 9/Classic.

[CharlesS]

Originally posted by BuonRotto:
I have no technical knowledge of this stuff, but I'll point out some things that I understood about why the Finder is Carbon:

1. I heard that it needed to be Carbon to interact with Classic, Classic files (sans extensions, with extra forks) and so forth.

Absolutely wrong. Cocoa and Classic can interact using any and all methods that Carbon and Classic can. You can test this yourself by sending AppleScripts, dragging and dropping text, copying and pasting, etc. between Cocoa and Classic. It works fine. And Cocoa apps can deal with type/creator codes, resource forks, and the like through LaunchServices and CoreServices. If you want proof, my Cocoa app, Pacifist, is able to put the type/creators and resource forks on the few remaining files that have them in the Apple install packages. I also have a Cocoa resource editor in development which is severely lacking in functionality, but which nevertheless works.

On top of all this, if there were something that was only possible with Carbon, it's still moot because Cocoa apps can even link against Carbon and use any of its functions.

Cocoa has no problems dealing with Classic or any of its little uniquenesses. The only thing it can't do is run under OS 9, but neither can the Mach-O Carbon Finder.

The only think keeping Apple from writing a Cocoa Finder is practicality. The fact that the benefits would probably not outweigh the costs is a factor. Any technical limitations of Cocoa in dealing with Classic are not.

[hudson1]

I think there could be an additional reason for why the Finder is Carbon that dovetails with the dogfood argument. Apple realized early in it's OS X development that Carbon would be the lifeblood of OS X since developers of monolithic apps (notably MS Office) made it clear that complete rewrites of huge programs just weren't feasible. With the priority on getting Carbon right and getting it early, what better in-house app did Apple have that would provide a very robust test-bed for Carbon? In other words, if Apple could make a Carbon Finder work well, then you could be relatively assured that the bugs were found and fixed. Using AppleWorks as the litmus test-bed might not have so thoroughly done that critical job.