the CAptain
Registered
Im aware that the current finder is based on the Carbon API and I was wondering if Apple is currently rewriting the finder in Cocoa? Im looking forward to the an reaction lever up to par with to OS 9.1 at the least.
When can we expect a Cocoa based finder?
- Thread starter the CAptain
- Start date
Rumors on the mac sites I frequent suggest two reasons for a Carbon Finder.
1. Cocoa was not quite ready for prime time when the finder was built. Not enough of it was ready.
2. Apple wanted to prove that porting to Carbon could be done, so they Carbonized their livelyhood.
All in all I think the finder is ok. It just needs some serious optimization. The Finder window resize needs to be replaced with a method similar to OS 9.
Also the Dock needs some work. However, I can't put my finger on why I don't like it. Maybe I'm just not qualified to make recommendations for improvement.
2¢
g
1. Cocoa was not quite ready for prime time when the finder was built. Not enough of it was ready.
2. Apple wanted to prove that porting to Carbon could be done, so they Carbonized their livelyhood.
All in all I think the finder is ok. It just needs some serious optimization. The Finder window resize needs to be replaced with a method similar to OS 9.
Also the Dock needs some work. However, I can't put my finger on why I don't like it. Maybe I'm just not qualified to make recommendations for improvement.
2¢
g
endian
Dis Member
I'm sure there was a lot of old code in the Finder that was easier to port to Carbon rather than rewrite for Cocoa. And Cocoa is only now gaining the ability to access traditional Mac stuff like HFS type/creator codes.
I hope Finder stays Carbon, since it gives Apple an immediate incentive to improve Carbon to be on a par with Cocoa; virtually every app people use on MacOS9 is going to be a Carbon app on OSX - not Cocoa.
I hope Finder stays Carbon, since it gives Apple an immediate incentive to improve Carbon to be on a par with Cocoa; virtually every app people use on MacOS9 is going to be a Carbon app on OSX - not Cocoa.
theCaptain
Member that enjoys Meece
Can a carbon app be optimized to run at the same speed as a cocoa app? I just would like to get the finder to a more reactive level. Dont get me wrong I love Aqua but I just wish that it had the same responsiveness as OS 9.1.
Carbon is just as low level as Cocoa.
It has the SAME access to the system as Cocoa.
It is better than Cocoa from a developer's standpoint.
It is a MAJOR accomplishment by Apple that programs can run on 9 and X with no recompile.
Carbon is NOT A HALF BREED by far.
You guys should be applauding Apple for a job well done on Carbon.
-Zach
It has the SAME access to the system as Cocoa.
It is better than Cocoa from a developer's standpoint.
It is a MAJOR accomplishment by Apple that programs can run on 9 and X with no recompile.
Carbon is NOT A HALF BREED by far.
You guys should be applauding Apple for a job well done on Carbon.
-Zach
endian
Dis Member
I don't know if I agree with that one (depends on the developer, I guess) but the rest I agree with. Think about MacOSX without Carbon - Photoshop wouldn't be ported, no MS Office, Illustrator, Freehand, Quark or Maya, the only web browser would be OmniWeb, which great as it is just plain doesn't work with many sites... Apple tried to push a Cocoa-only OS with Rhapsody, but Mac developers weren't interested. There was an article by someone at Omni stating that Carbon was THE most important aspect of OSX, which coming from someone as involved with Cocoa as Omni is saying a lot
theCaptain
Member that enjoys Meece
My real question is, with lots of optimization of the current Carbon based finder, can it be made to run as quickly, and be as responsive as a finder developed from the ground up in Cocoa.
I do agree, Carbon is great, and with out it OS X could simply not survive.
I do agree, Carbon is great, and with out it OS X could simply not survive.
Heres the developer's standpoint I was talking about:
On the average, when using Carbon, a program is already 90% done when the porting process begins. In contrast, when using Cocoa, you can only reuse the OS independent code. Porting to Cocoa is almost as large a project as porting from PC to Mac. You have to rewrite Messaging, Threading, GUI, 2D Drawing, Network, etc. Plus, you have to adjust to Objective-C. The cost difference between these two alternatives is large ... AND little of the advantage that Cocoa fans brag about has been seen (quicker time to market, faster code).
I like Cocoa fine, but I don't view Carbon as its red-headed stepson. Frankly I'm getting tired of people bitching about Carbon. Mac OS X would have a very rough road to acceptance without it.
To answer your question though, yes, the Carbon finder can be just as fast as any Cocoa based finder, assuming all the code (Carbon and Cocoa) is optimized with equal effort. I don't think the finder is done being optimized (its definitely better in 10.0.4 though!)
On the average, when using Carbon, a program is already 90% done when the porting process begins. In contrast, when using Cocoa, you can only reuse the OS independent code. Porting to Cocoa is almost as large a project as porting from PC to Mac. You have to rewrite Messaging, Threading, GUI, 2D Drawing, Network, etc. Plus, you have to adjust to Objective-C. The cost difference between these two alternatives is large ... AND little of the advantage that Cocoa fans brag about has been seen (quicker time to market, faster code).
I like Cocoa fine, but I don't view Carbon as its red-headed stepson. Frankly I'm getting tired of people bitching about Carbon. Mac OS X would have a very rough road to acceptance without it.
To answer your question though, yes, the Carbon finder can be just as fast as any Cocoa based finder, assuming all the code (Carbon and Cocoa) is optimized with equal effort. I don't think the finder is done being optimized (its definitely better in 10.0.4 though!)
rharder
Do not read this sign.
I have to concede Zach's points about the benefits of Carbon, but still, for the most important appliation in the system to <em>not</em> be in the system's native architecture (and lacking a Services menu 
) seems a little odd.
But as we've been saying, this is essentially version 1.0 of Mac OS X (yeah, yeah, NextStep, OS X Server, etc) so I don't mind giving Apple a little slack.
Remember when the PowerPC architecture came out, and we were disappointed that Apple hadn't converted 100% of their code to PPC right away? It's just not feasible on a tight timeline.
-Rob
) seems a little odd.But as we've been saying, this is essentially version 1.0 of Mac OS X (yeah, yeah, NextStep, OS X Server, etc) so I don't mind giving Apple a little slack.
Remember when the PowerPC architecture came out, and we were disappointed that Apple hadn't converted 100% of their code to PPC right away? It's just not feasible on a tight timeline.
-Rob
RacerX
Old Rhapsody User
Having worked with "Finder" replacements that are Cocoa based, I have noticed that calls to launch Carbon apps always end up launching Classics as well. Apple has yet to add the APIs to Cocoa that would let it tell the difference between Carbon and Classic (and other short coming pointed out, not to delicately by strobe, in another thread). The speed of the Workspace Manager of OPENSTEP/Rhapsody/Server 1.x came from years of work. Many of the features were added long after the original version was first released in 1988. Todays Finder has far more to do than the original Finder(Multi-Finder) or the Workspace Manager of the past. We ask far more than the early users of those apps, and that is not counting the need to have the Finder work with both Carbon and Cocoa. Because the Finder is built in both Project Builder and Interface Builder, I would not be surprised to see Apple put more work into bringing both Carbon and Cocoa together as has been done with Objective C and Java in Cocoa.
RacerX
Old Rhapsody User
rharder: "Hardware: Etch-a-Sketch
Operating System: Shake to reboot"
That is cool! I had some friends that made a Y2K kit for Etch-a-Sketches. The instructions had you write out 12-31-1999, shake, then write 1-1-2000. If it worked, your Etch-a-Sketch was Y2K compliant and they included a sticker saying so that you could put on it after words.
Operating System: Shake to reboot"
That is cool! I had some friends that made a Y2K kit for Etch-a-Sketches. The instructions had you write out 12-31-1999, shake, then write 1-1-2000. If it worked, your Etch-a-Sketch was Y2K compliant and they included a sticker saying so that you could put on it after words.
strobe
Puny Member
To this day Cocoa is incapable of being used to make the OS X Finder. Cocoa can't copy files any better than the 'cp' command, Cocoa doesn't understand file types/creators, Cocoa can't make, resolve, or otherwise deal with aliases. There are some even more obscure reasons Cocoa could not be used, even now.
I think you Cocoa proponents need to shut the hell up, at least until Cocoa is up to speed on all the great things the mac has like FSRefs.
Carbon apps can be lightening quick, support high quality text rendering, and load plugins which are linked to Cocoa or any other library. Once more Carbon programmers use Carbon events and MLTE/ATSUI you will see these changes. Right now only CarbonLib 1.2.5 and higher support Carbon events which is probably why a lot of Carbon apps don't use them, only CarbonLib 1.0.4 works on System 8.1 (why this is, I don't know for sure).
Personally I would rather the current bugs in OS X Carbon be fixed. For example OS X Carbon can't set the ownership of files while MacOS 9 can copy the UNIX ownerhip just fine. This breaks Synk X in OS X (works great in MacOS...I can backup/copy an entire bootable OS X volume!). Also there is an event-eating bug which causes Drop Drawers X in OS X to eat keyboarding events when they should be released. Again no problem in MacOS. I could mention dozens of others but I think I've made my point.
I think you Cocoa proponents need to shut the hell up, at least until Cocoa is up to speed on all the great things the mac has like FSRefs.
Carbon apps can be lightening quick, support high quality text rendering, and load plugins which are linked to Cocoa or any other library. Once more Carbon programmers use Carbon events and MLTE/ATSUI you will see these changes. Right now only CarbonLib 1.2.5 and higher support Carbon events which is probably why a lot of Carbon apps don't use them, only CarbonLib 1.0.4 works on System 8.1 (why this is, I don't know for sure).
Personally I would rather the current bugs in OS X Carbon be fixed. For example OS X Carbon can't set the ownership of files while MacOS 9 can copy the UNIX ownerhip just fine. This breaks Synk X in OS X (works great in MacOS...I can backup/copy an entire bootable OS X volume!). Also there is an event-eating bug which causes Drop Drawers X in OS X to eat keyboarding events when they should be released. Again no problem in MacOS. I could mention dozens of others but I think I've made my point.