[graphics84]

"...it's still only a rumor at this point, but it has been reported through multiple avenues that the new Finder, while still retaining a non-trivial amount of its old code, will become a Cocoa application!"

this is from Macosrumors.com

why would this be good?

what would that do?

[OptimusG4]

Originally posted by graphics84:

this is form Macosrumors.com

Red flag going off yet?

[Adam Betts]

So far MacOSRumors.com have been 0% accurate

[foamy]

I don't care if it is written in RealBasic or Applescript Studio or COBOL or Pascal or whatever as long as it doesn't suck like the current finder does.

[warpmoon]

There's nothing wrong discussing rumors. The fact that said rumors comes from macosrumors changes nothing, right?

[graphics84]

who cares if it's a rumor... I didn't post it to debate the merits of macOSrumors...

I'm just curious why a finder writen in Cocoa is better than the current Finder...

that's the question..

start another post if you want to talk about how crappy macosrumors is.

[warpmoon]

Originally posted by graphics84:
who cares if it's a rumor... I didn't post it to debate the merits of macOSrumors...

I'm just curious why a finder writen in Cocoa is better than the current Finder...

that's the question..

start another post if you want to talk about how crappy macosrumors is.

Actually, I'm on your side, my twist at the end was more of a tease directed towards the macosrumor-haters.

[DoctorW]

Originally posted by Adam Betts:
So far MacOSRumors.com have been 0% accurate

I would guess they would prefer it if you said they are 100% inaccurate.

[Sarc]

<sarcasm>

Mac OS Rumorsm Wednesday, April 2:

We have been hearing a lot from the grapevine lately, but so far the most promising is that Mac OS X 10.3 Codenamed Panther will be released in the future.

Also another Safari Build is expected in the future.

</sarcasm>

[Phoenix1701]

The answer to your question, since no one else has jumped to the bait, is that many people feel Cocoa applications are, on the whole, better designed and better programmed. While this is not strictly true, I have found that many Cocoa applications tend to perform better than many Carbon applications -- this is not because of any programmatic difference between the two frameworks, but rather (I suspect) more because Objective-C and the Cocoa framework is a lot easier to program in than Carbon is. This means two things:
(1) most programs designed specifically for Mac OS X are written in Cocoa, not Carbon, and many Carbon applications are ports of Classic applications which are not always optimized or entirely updated for Mac OS X (some are missing features like ATSUI font smoothing, live resizing, etc.)
(2) Carbon's memory management is a lot hairier than Cocoa's, so there's more opportunity for instability (though believe me, it's not at all difficult to write a Cocoa application that leaks memory like a sieve).
The upshot of all this is that people think if the Finder was rewritten in Cocoa it would be more stable. This is probably true. However, it is also true that if the Finder was rewritten correctly in Carbon it would be just as stable, and considering realistically it's impossible to reuse Carbon code in Cocoa applications in anything but very small chunks (the entire design philosophy is different), if and when they do recode the Finder, they'll probably do it in Carbon.
That said, I hope they do something about it soon... I've come across several operations that work subtly differently depending on minute and obscure details (like whether the user has resized the column headers in list view) that imply to me that different functions are getting called internally to handle almost identical operations. What this probably means is that the Finder's code is modularized the wrong way, into sections that no longer make any sense based on the way the current Finder works. If I were programming this, I'd probably be considering a complete rewrite too.

[simifilm]

Rewriting the finder in Cocoa would be a waste of time. There's nothing wrong with Carbon per se, you just have to code it well.

[kybernaut]

Originally posted by graphics84:
I'm just curious why a finder writen in Cocoa is better than the current Finder...

At least you could use inactive widgets like scroll bars and buttons *directly* without activating that window first... This really drive me nuts with the current finder...

kybernaut

[Adam Betts]

There were a long thread on this topic. A simple search will find it easily. Lot of people with great knowledge of cocoa and carbon posted in that thread.

BTW, Im curious... Why would you want to know if Finder written in Cocoa will be better than current Finder? Will it affect the way you work or something?

[CheesePuff]

Originally posted by Adam Betts:

BTW, Im curious... Why would you want to know if Finder written in Cocoa will be better than current Finder? Will it affect the way you work or something?

Because we all know that Cocoa is so superior to Carbon!!!

[graphics84]

Originally posted by Adam Betts:
There were a long thread on this topic. A simple search will find it easily. Lot of people with great knowledge of cocoa and carbon posted in that thread.

BTW, Im curious... Why would you want to know if Finder written in Cocoa will be better than current Finder? Will it affect the way you work or something?

no I'm just trying to figure out why MacOSrumors would be so excited about it... I don't know the differnece other than apps written in both seem to work on OS X and apps written in carbon work in OS 9 too...

that's all

by the way I like your web portfolio, checked it in another thread

[pat++]

Originally posted by CheesePuff:
Because we all know that Cocoa is so superior to Carbon!!!

We all know that Carbon still has debug code� included as opposed to Cocoa.

[trusted_content]

This Cocoa vs. Carbon stuff is especially funny given that it's common knowledge that carbon apps are faster AND more low-level. It all comes down to using a C api or an Objective-C API that requires a runtime and much more overhead. Cocoa is a better API because it doesn't require using archaic toolbox methods (I think Carbon still requires Pascal strings too, wtf, you'd think they would have moved beyond that by now) and is designed specifically for writing OS X apps.

But the audio app I'm writing will pretty much HAVE to be carbon for speed, which is why I'm not exactly pleased that I have to learn another API, and a rather baroque one at that.

[pat++]

Originally posted by trusted_content:

But the audio app I'm writing will pretty much HAVE to be carbon for speed, which is why I'm not exactly pleased that I have to learn another API, and a rather baroque one at that.

Can you elaborate on this? what are you doing? How would Cocoa to be too slow?
Cocoa is basically related to UI. Any overhead from Objective-C would be unnoticable in most cases.

[-Q-]

Speaking of the Finder, John Siracusa has an interesting article on why the current finder sucks and what should be changed about it.

I'll be happy with not having a network dialogue block access to doing something else in the finder....

[Terri]

Actually I hear they are bringing back HyperCard and will be using it to write the next Finder.

[graphics84]

Originally posted by Terri:
Actually I hear they are bringing back HyperCard and will be using it to write the next Finder.

*LOL*



that was a dig... nice

[smeger]

Originally posted by trusted_content:
But the audio app I'm writing will pretty much HAVE to be carbon for speed, which is why I'm not exactly pleased that I have to learn another API, and a rather baroque one at that.

For speed, you'd want to bypass Carbon altogether and use CoreAudio. The Core* stuff underlies both Carbon & Cocoa, and is a nice, modern API, unlike Carbon.

You can mix & match CoreWhatever and Carbon/Cocoa, so your app could have a Cocoa interface and use CoreAudio for the, well, audio.

[Anomalous]

MacOSRumors has seemed pretty accurate to me.

[gralem]

Originally posted by graphics84:
who cares if it's a rumor... I didn't post it to debate the merits of macOSrumors...

I'm just curious why a finder writen in Cocoa is better than the current Finder...

that's the question..

start another post if you want to talk about how crappy macosrumors is.

The BEST answer for your question would be that (from what I hear) Cocoa has less debug code in it. You can draw your own conclusion from that.

Now for a serious additional question: is carbon "threadable"? This might be the biggest reason to rewrite in Cocoa. Couldn't threads solve most finder-related beach-ball issues? So I'm thinking that OS9/Carbon is non-threadable.

---gralem

[Developer]

Originally posted by gralem:
Is carbon "threadable"? This might be the biggest reason to rewrite in Cocoa. Couldn't threads solve most finder-related beach-ball issues? So I'm thinking that OS9/Carbon is non-threadable.

Carbon is threadable. MP threads in Carbon/OS X and NSThreads in Cocoa both base on pthreads so threading is equivalent. Both APIs are "rather" thread safe (but not completely).
Neither Carbon nor Cocoa applications get threading automatically.

[neoTony]

Developer, quick question that you may or may not be able to answer:

pthreads in xnu/darwin - are they finalised? I know that the gcc included with the latest dev tools doesn't understand them, but I'm getting the impression that the implementation is lacking or unfinished in some form.

I've been getting down and dirty with GNOME 2.2.1 on fink, and noticed the pages of spurious "-pthreads" not understood errors from cc....

[Millennium]

Originally posted by graphics84:
why would this be good?

what would that do?

Basically nothing, in and of itself. There are some blind Cocoa zealots who will try and argue that making something Cocoa somehow automatically makes it better; this isn't really true.

Carbon apps could theoretically have a speed advantage over Cocoa apps performing the same function. However, since both the Carbon and Cocoa API's deal primarily with the interface, the speed advantage wouldn't be noticeable in any practical situation. Artificial scenarios, such as the famed Let1kWindowsBloom, would show a noticeable speed advantage for Carbon, however no real-world interface is that taxing.

Why do I say "well-programmed app"? A truly well-programmed app wouldn't use either Cocoa or Carbon for the actual performance-critical stuff. Cocoa and Carbon are interface API's, not really meant for those situations where performance is really important. Such an app would use Cocoa or Carbon only for the interface, and use something else for the backend processing. Many of the best apps for OSX -including both Safari and Camino- use this technique.

And in the end, Cocoa vs. Carbon won't matter, because Cocoa will be Carbon. Apple has been working on unifying the interfaces, so that Cocoa will become essentially another level of abstraction on top of Carbon. Everybody wins in this scenario; Apple will have to give Cocoa access to Carbon's richer set of interface controls, but in turn they'll have to ensure that Cocoa's currently-superior system-integration technologies are folded into Carbon. Some of this work is already present in Jaguar, with the new HIView system for controls.

[stew]

A crappy Finder is a crappy Finder, Cocoa or not. It's not the API that makes an application good or bad.

[waffffffle]

Originally posted by Millennium:
And in the end, Cocoa vs. Carbon won't matter, because Cocoa will be Carbon. Apple has been working on unifying the interfaces, so that Cocoa will become essentially another level of abstraction on top of Carbon. Everybody wins in this scenario; Apple will have to give Cocoa access to Carbon's richer set of interface controls, but in turn they'll have to ensure that Cocoa's currently-superior system-integration technologies are folded into Carbon. Some of this work is already present in Jaguar, with the new HIView system for controls.

Yes I've heard this too. Carbon and Cocoa will be unified in the future. That will be very cool for developers.

[fireside]

im still trying to figure out where people get off saying that carbon apps are faster than cocoa apps.

on a macosrumors related note, they said that apple might release 10.2.6 sometime before 10.3. also strange rumors about 10.3 having quad-processor support. i always thought that OS X has always had support for upto 32 processors

[exca1ibur]

OSX only has support for 2 processors, for now. Just type in 'hostinfo' in the terminal and it will tell you.

[stew]

Originally posted by fireside:
im still trying to figure out where people get off saying that carbon apps are faster than cocoa apps.

Build-time linking vs run-time linking. Cocoa is trading speed for flexability.

[dfiler]

Originally posted by fireside:
im still trying to figure out where people get off saying that carbon apps are faster than cocoa apps.

In my experience, heavy use of NSView and its subclasses is what slows down a cocoa app. NSView is powerful but perhaps too bloated for the tasks it is sometimes used for. When given the choice, developers tend to not re-implement hierarchical, layer-based drawing architectures from scratch... they simply use the functionality provided by NSView.

In general, Cocoa is a higher-level API. While this makes life easier for programmers, it also produces slightly slower code. (usually) However, a more significant difference is in how many levels of abstraction a function call must pass through. When Cocoa was ported/modified for use in OS X, many of its calls became simple wrappers of existing routines. Word has it that Apple is continuing further down this path, providing more of Cocoa�s functionality via Carbon function calls.

While Cocoa is a more �modern� API, if your development team is well versed in Carbon and your code base is heavily Carbon, programming in Carbon will likely produce a better product.

[Millennium]

Originally posted by fireside:
im still trying to figure out where people get off saying that carbon apps are faster than cocoa apps.

Not that they are, but they can be.

It has to do with the dynamic nature of Cocoa's runtime. That does, necessarily, entail a performance hit. This performance hit is very small; you wouldn't even notice it unless you were performing hundreds of GUI-intensive operations. But it is there, and Carbon apps can eke out just a little more speed because of that.

In most real-world apps, humans would never perceive this difference. The one real-world app where it's ever come into play on a noticeable level is OmniWeb, which uses NSView in its rendering engine so heavily that it affects performance.

There's also the issue of Cocoa's storage classes, NSArray and NSDictionary. These are incredibly useful for certain purposes; they're made to be pretty generic. But you know what they say about jacks of all trades: because they have to be generic, design decisions had to be made which impact performance. If you abuse these classes too heavily, then those decisions will impact your app's performance too.

That's the thing: it's possible to make bad apps in Cocoa. To make a bad app in Carbon, you just have to not take advantage of Carbon's technology. To make a bad app in Cocoa, you just have to take too much advantage of Cocoa's technology, to the point where you use it at inappropriate times.

Anyway, that's how a Carbon app can be faster than a Cocoa app. A good programmer using either toolkit can make apps where you wouldn't be able to see any performance difference. A bad programmer, on the other hand, can screw up anything, even Cocoa.

[fireside]

Originally posted by Millennium:
Not that they are, but they can be.
...
Anyway, that's how a Carbon app can be faster than a Cocoa app. A good programmer using either toolkit can make apps where you wouldn't be able to see any performance difference. A bad programmer, on the other hand, can screw up anything, even Cocoa.

thats what im talking about. it feels that these people are saying that all cocoa apps are horribly slow and all carbon apps are much better. which just isnt true. look at Safari. then look at IE.

[dfiler]

Originally posted by fireside:
thats what im talking about. it feels that these people are saying that all cocoa apps are horribly slow and all carbon apps are much better. which just isnt true. look at Safari. then look at IE.

I don't think that is the impression that most posters here are trying to convey. Most of the explanations above did a good job of touching on a subset of the differences between carbon and cocoa. Neither environment is inherently better for real world application developement right now. Cocoa is certainly cleaner in its design, but this isn't the only or paramount criterion for evaluation.

True, Safari is Cocoa and IE is carbon. However, this alone isn't an indication of which API/framework produces quicker executing binaries. I would be willing to bet that Safari handles its own rendering without much use of the heavy-weight class NSView. The bulk of CPU time consumed by browsers is used for page layout and rendering. If each browser rolls their own rendering engine, performance is indicative of application code efficieny rather than the efficieny of cocoa vs carbon.

[hellmachine]

Originally posted by simifilm:
Rewriting the finder in Cocoa would be a waste of time. There's nothing wrong with Carbon per se, you just have to code it well.

there is. it looks shitty in the details. no matter how it is programmed. i think its because internally carbon apps are just themed with the appearance manager...
whatever, many gui features aren�t available via carbon. this may change because there are options to mix carbon and cocoa... we will see.

[Amorph]

Originally posted by Millennium:

And in the end, Cocoa vs. Carbon won't matter, because Cocoa will be Carbon.

However, Apple will probably still continue moving toward Cocoa just because the speed hit is worth the more rapid development and smaller, cleaner codebase.

If there's a reason to rewrite the Finder in Cocoa, it's so that fewer developers can make more fixes and changes in less time, and make fewer mistakes in the first place given that fewer lines of code generally means fewer bugs (but with the tradeoff that if they found a bug in the framework libraries, they'd have to wait for another team to fix it).

[bradoesch]

Originally posted by exca1ibur:
OSX only has support for 2 processors, for now. Just type in 'hostinfo' in the terminal and it will tell you.

Can Apple easliy configure the kernel for 4 (or more) processors? Is there a disadvantage to using a kernel configured for 4 processors running on a system with only 1?

[bradoesch]

Originally posted by foamy:
I don't care if it is written in RealBasic or Applescript Studio or COBOL or Pascal or whatever as long as it doesn't suck like the current finder does.

I'd actually prefer if it was somehow written in QBasic. I'd imagine I'm quite alone with that idea.

[GRAHAMUK]

Originally posted by trusted_content:
This Cocoa vs. Carbon stuff is especially funny given that it's common knowledge that carbon apps are faster AND more low-level. It all comes down to using a C api or an Objective-C API that requires a runtime and much more overhead.

Do a stack trace into many common carbon functions and guess what - they call down into Cocoa methods! (Most notably text measurement, but in many other cases too). So this argument is false.

FWIW, Carbon apps can be just as fast/stable/<your favourite plus point here> as Cocoa apps, but they do have to be well written. That's the biggest problem - a lot of developers simply don't know how to do that. Tricks that worked in the classic Mac OS often have the opposite effect on performance in the Carbon world.

[Synotic]

Originally posted by fireside:
thats what im talking about. it feels that these people are saying that all cocoa apps are horribly slow and all carbon apps are much better. which just isnt true. look at Safari. then look at IE.

For the rendering engine, Safari uses KHTML which certainly isn't written in Objective-C. As for the interface it's seems pretty much the same. Now look at OmniWeb which is Cocoa goodness, IE is much faster. Another example is Transmit 1.7 (Carbon) to Transmit 2 (Cocoa). Interface-wise Transmit 2 feels slower.

Now... maybe someone better versed in programming can phrase this better... But if I want to do something really quickly I'll pull up GoLive opposed to say Create. This is because the interface is a lot faster. But I feel I have to be a lot more careful. For instance... if I press button that changes content... 500 times, there's a good chance it'll mess up, but it'll be fast. Now with Cocoa, it's feels a lot stabler. If I were to do the same thing, I'd probably get 20 seconds of lag before it did anything and then 1 second before each registered click. But it would handle it. Cocoa apps seem to be like programs that can handle heavy-use and with good processors, it'll really show through.

Does anybody else understand what I mean?

[Seamus]

Cocoa is a great development environment because so much is handled by the OS rather than the application. It means I can spend less time figuring out how to get a scrollbar to work and more time on actual functionality. I think that's where the speed hit/bugs in Carbon arise: The UI functions that your average app dev will write are more prone to failure than Apple's own UI functions.

What I want to know is *why* a Cocoa finder would be so "difficult." File access APIs are built into Cocoa, and I can't imagine calling upon the includes they depend on would be overly difficult.

[Catfish_Man]

Originally posted by Seamus:
Cocoa is a great development environment because so much is handled by the OS rather than the application. It means I can spend less time figuring out how to get a scrollbar to work and more time on actual functionality. I think that's where the speed hit/bugs in Carbon arise: The UI functions that your average app dev will write are more prone to failure than Apple's own UI functions.

What I want to know is *why* a Cocoa finder would be so "difficult." File access APIs are built into Cocoa, and I can't imagine calling upon the includes they depend on would be overly difficult.

It seems like most of the Finder could just be a front end for ls, ditto (or cp), mv, mkdir, etc... which would be really easy to do.

[Phoenix1701]

Originally posted by Synotic:
For the rendering engine, Safari uses KHTML which certainly isn't written in Objective-C.

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.
What this means is that you need only use syntax that is unique to Objective-C (things that look like [object methodWithArg1:val Arg2:val2]) if you feel like it. If, rather than using the Cocoa/CoreFoundation niceties like NSArray and NSString, you decide you want to use standard issue C-style arrays, you are perfectly free to do so. Of course, the interface to a Cocoa application is written using CoreFoundation constructs, so when you want to communicate with those elements you will need to use Objective-C. But there's nothing that says you can't just have that Objective-C method call a simple C function that does all the work. That's why people have been saying that the performance difference will quite literally never matter; the difference in speed you get from clicking a button in a Cocoa app and triggering an action method rather than clicking on a button in a Carbon app and triggering an event handler function (or whatever) is next to nothing... and that's the only part of the program that must be written in Obj-C for Cocoa apps.

That make sense? :)

[exca1ibur]

Can Apple easliy configure the kernel for 4 (or more) processors? Is there a disadvantage to using a kernel configured for 4 processors running on a system with only 1?

I assume they could recompile the kernal for more CPU support. No disadvantage I can think of. I'd guess the more CPUs they support the better the threading would have to be coded for the OS. I'd see that as a good thing. Might kill those Beachballs. LOL

[rmendis]

Originally posted by graphics84:
...it's still only a rumor at this point, but it has been reported through multiple avenues that the new Finder, while still retaining a non-trivial amount of its old code, will become a Cocoa application!

Well, originally the 'Finder' evolved from the Cocoa Workspace Manager in NEXTSTEP/Rhapsody. Why did they re-write(?) it as a Carbon app...now again re-writing it as a Cocoa app...it's going round in circles and doesn't make any sense.

What was the reason for writing a Cocoa Finder in Carbon in the first place?

[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. It was easier to recycle the finder's code-base than it was to start from scratch with Cocoa.

I think the finder sucks...
However, I don't think it currently has anything to do with Carbon vs. Cocoa. In the long term, Cocoa code may prove easier to maintain and extend, but in the short term, the finder code base and developer core competencies are in Carbon. If the Cocoa rewrite rumors are true, it seems as if Apple made the correct decision. Rework the Carbon finder of OS 9 for Darwin while working on an eventual replacement in Cocoa.

[bewebste]

Originally posted by GRAHAMUK:
Do a stack trace into many common carbon functions and guess what - they call down into Cocoa methods! (Most notably text measurement, but in many other cases too). So this argument is false.

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.

[rmendis]

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. It was easier to recycle the finder's code-base than it was to start from scratch with Cocoa.

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.

2. Mac OS X's window server is hellova lot more like NEXTSTEP/Rhapsody's window server than Mac OS 8/9's. In fact it should be fairly irrelevent to Cocoa apps most of the time.

No. After having a fairly thorough Cocoa Finder, Apple spent several man months/years re-doing it in Carbon. In my mind the only *real* reason to do this is if Apple was thinking of at some stage to back port the Mac OS X Finder to Mac OS 9/Classic. That's what Carbon apps have in advantage over Cocoa apps.