Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Leopard Finder: Finally Cocoa?

T

teekayx

macrumors newbie
Original poster
Jun 22, 2007
25
1
The Thread topic says it all - does anyone know if the new Finder is now fully Cocoa based or is it still using Carbon? I am sick and tired of network hangs and such stuff which happens with the current Finder (Which seems to only work single-threadedly) and am looking forward to Leopard and hoping that it has been rewritten.
Somehow I have this gutfeeling, that they put this "Eyecandy"-Feature Coverflow on top of the old finder and changed nothing underneath.. what do you guys think..

and hi all, my first post here :)
 
I saw a post somewhere (sorry it'd take ages to find) that said that it's still Carbon, but with some Cocoa views (Coverflow for example). Note that it being Carbon does not mean it can't be multi-threaded.

The Network thing is an OS level issue, not really a Finder issue. This is sorted in Leopard via AutoFS.
 
Let me break the ice here...

I don't think any of you know for sure whether or not Leopard's is Carbon or Cocoa. Where are the facts? You can't base it off poor credibility. No one probably knows, unless you're a developer or insider. In this case, your guesses are probably as good as mine.

Last time I heard, Leopard was built Cocoa from the ground up. :)
 
The Finder in Leopard is 32-bit and mostly Carbon. There is no reason for it not to be. It does not need to support a huge memory space and the code is already written in Carbon (and for certain file handling an monitoring aspects you have to drop to the procedural C API (aka Carbon) anyway as there is no Cocoa equivalent).

The info comes from: http://www.carbondev.com/site/?page=64-bit+Carbon

I quote:
"Q: After all, aren't most of the Cocoa APIs implemented on the HIToolbox stuff now?"

No; primarily just the menu classes (NSMenu and NSMenuItem), which use the Carbon Menu Manager. The Cocoa event system also calls into the Carbon Event Manager to fetch events from the event queue. No other parts of AppKit are implemented on top of HIToolbox, or ever have been.

No, the Finder in Leopard is a 32-bit app. The only Leopard app I'm aware of that ships as a 64-bit app is Xcode.

No, the Finder is still largely a Carbon app in Leopard, although it does use our new HICocoaView capability to allow embedding NSViews inside a Carbon window to implement the coverflow view.

Currently plans call for the Carbon Event Manager to continue to be available in 64-bit HIToolbox, but not the Menu Manager.

HITheme is currently undecided. We did hear from multiple developers at the conference today who use HITheme and would like to see it in 64-bit.

-eric schlegel
 
I think the Finder needs a serious update (network hangs annoy the hell out of me) but as is stated elsewhere it is unlikely that that will happen soon. Hopefully Leopard+1 will have a new finder! :)
 
aspro said:
I think the Finder needs a serious update (network hangs annoy the hell out of me) but as is stated elsewhere it is unlikely that that will happen soon. Hopefully Leopard+1 will have a new finder! :)
Click to expand...

Network stalls hanging the whole Finder are fixed in Leopard but not by altering the Finder. The new AutoFS multi-threaded filesystem layer fixes this for the Finder and every other app. A much better solution than just fixing the Finder.
 
robbieduncan said:
Network stalls hanging the whole Finder are fixed in Leopard but not by altering the Finder. The new AutoFS multi-threaded filesystem layer fixes this for the Finder and every other app. A much better solution than just fixing the Finder.
Click to expand...

Thanks for the AutoFS link, robbieduncan, I'd not seen that before.

It's a shame Finder always copped the flak for shoddy fileshare handling. It wasn't Finder's fault that mounting a filesystem was a blocking operation. I'm imagining Apple preferred to put together a complete all-encompassing fix in the form of AutoFS rather than stick a quick workaround in for this problem.

Incidentally, XP's Explorer -- while better behaved than Finder -- also sometimes craps out when shares disappear.
 
afornander said:
all of leopard is 64bit. finder is part of leopard, that makes it 64bit. 64bit=cocoa. the new finder is cocoa, if i remember correctly they said that at wwdc07.

apple 64bit link - http://www.apple.com/macosx/leopard/technology/64bit.html

also on this page is a pic of finder, common sense that its 64 bit.:cool:

the original was cocoa, this is a new finder!!!
Click to expand...
Seriously? I can't tell if you're kidding. If not, that was pretty dumb.
 
hi

hi i am new to this mac world
i want to know the details of how DMG images are created..
plz hekp me out from this problem.........
thanks in advance..
 
afornander said:
all of leopard is 64bit. finder is part of leopard, that makes it 64bit. 64bit=cocoa. the new finder is cocoa, if i remember correctly they said that at wwdc07.
Click to expand...


Writing it in bold doesn't make it right.

1. All of Leopard is both 64 bit and 32 bit. Applications are completely independent of that.

2. Leopard runs on 32 bit CPUs. Therefore, the Finder cannot be present only in a 64 bit version unless Apple went completely bonkers.

3. There are very good technical reasons not to make an application 64 bit unless you have a very, very good reason to do so. In the case of the Finder, there are no good reason to make it 64 bit, so it isn't 64 bit (unless Apple went completely bonkers).

4. Cocoa makes it easier to write code in certain situations. So if Apple wanted to write a brand new application, it would most likely be Cocoa because that is less work. However, leaving an existing Carbon application alone is even less work by a very significant factor. I don't know if the Finder was Cocoa or Carbon, but it wouldn't have changed.

5. For a user, it doesn't make the slightest difference whether an application is written in Carbon or Cocoa. In many cases, they can't even find out. Apart from developers and fanbois, nobody cares.
 
gnasher729 said:
Writing it in bold doesn't make it right.

1. All of Leopard is both 64 bit and 32 bit. Applications are completely independent of that.

2. Leopard runs on 32 bit CPUs. Therefore, the Finder cannot be present only in a 64 bit version unless Apple went completely bonkers.

3. There are very good technical reasons not to make an application 64 bit unless you have a very, very good reason to do so. In the case of the Finder, there are no good reason to make it 64 bit, so it isn't 64 bit (unless Apple went completely bonkers).

4. Cocoa makes it easier to write code in certain situations. So if Apple wanted to write a brand new application, it would most likely be Cocoa because that is less work. However, leaving an existing Carbon application alone is even less work by a very significant factor. I don't know if the Finder was Cocoa or Carbon, but it wouldn't have changed.

5. For a user, it doesn't make the slightest difference whether an application is written in Carbon or Cocoa. In many cases, they can't even find out. Apart from developers and fanbois, nobody cares.
Click to expand...

I'd agree.

Of all the apps to write in 64bit, Finder is one of the least important. Along with the dock, and Photo Booth :rolleyes:
 
It has been clearly stated numerous times in the cocoa and carbon mailing lists about Finder being a primarily Carbon application.

And thats with posts from Apple Developers telling us straight out, so search the mailing lists not the Apple products page before making a opinon.


PS. 64bit is just a buzz word, do research into it before asking for apps to be 64bit when there is no need
 
bigandy said:
I'd agree.

Of all the apps to write in 64bit, Finder is one of the least important. Along with the dock, and Photo Booth :rolleyes:
Click to expand...

i have to disagree with you here...(unless your being sarcastic i cant tell if u are, sorry)

the finder and dock are THE MOST important parts of leopard. they are the interface of the whole computer!!!!! they need to be the most reliable and most prefected parts of the OS. they tell the rest of the processes what to do and give out jobs based on what we tell them to do.

of course finder and dock are going to be 64bit.
 
DoFoT9 said:
the finder and dock are THE MOST important parts of leopard. they are the interface of the whole computer!!!!! they need to be the most reliable and most prefected parts of the OS. they tell the rest of the processes what to do and give out jobs based on what we tell them to do.

of course finder and dock are going to be 64bit.
Click to expand...

That's, uhhh... not true at all. But I'm hoping you know that and are just being silly.

The Finder is one of many processes running in OS X, and is entirely independent of them. The Mach kernel (what gives you the gray apple logo at startup) handles most of the "assigning". You can work perfectly fine without the Finder at all. Ever hear of PathFinder?

Ditto for the Dock, I suppose, though you'd need to use something else in its place-- maybe Quicksilver.

64-bit has absolutely nothing to do with reliability or "perfection".
 
Bluefusion said:
1.The Finder is one of many processes running in OS X, and is entirely independent of them. The Mach kernel (what gives you the gray apple logo at startup) handles most of the "assigning".

2.You can work perfectly fine without the Finder at all. Ever hear of PathFinder?

3.64-bit has absolutely nothing to do with reliability or "perfection".
Click to expand...

1.the finder handles not the actual processes of the computer, but the 1st layer of interactivity.... i.e. we move the mouse on the desktop, and double click a folder. that is the 1st stage, in the fact that it controls the 1st steps... i kno that from there on the mach kernal handles the 'assigning'

2. i am aware you can work without the finder, i have been using pathfinder for quite some time... it has also evidently stuffed up my finder...the fact that the finder now uses 100% cpu at all times worries me.. thats why i have been unable to use it. i have made a thread on here, but no1 could help me.

3.sorry i didnt add the fact that the 64-bit architecture will make everything run a hell of a lot faster (or have the potential to). the algorithms compared to 32-bit are just completely blown away by 64-bit. that was going to be my main point for that but i kinda forgot.
 
DoFoT9 said:
3.sorry i didnt add the fact that the 64-bit architecture will make everything run a hell of a lot faster (or have the potential to). the algorithms compared to 32-bit are just completely blown away by 64-bit. that was going to be my main point for that but i kinda forgot.
Click to expand...

Not really, clearly you don't understand the difference, in fact 64 bit can make some things slower.

The only applications that should be 64 bit are things like Photoshop as they want to hold more than 2GB of a image in the RAM at the same time.
 
semaja2 said:
PS. 64bit is just a buzz word, do research into it before asking for apps to be 64bit when there is no need
Click to expand...

On x86, 64bitness is a big benefit. On most other CPU's, 32bit vs. 64bit is just a question of addressable memory and some computational tasks. But on x86-CPU's, 64bit doubles the number of general purpose registers and SSE-registers. The number of register is one of the big drawbacks x86 has when compared to many other architectures. So 64bit in x86 gives benefits even in areas that do not need the "traditional" benefits of 64bit processor (bigger address-space etc.)
 
DoFoT9 said:
3.sorry i didnt add the fact that the 64-bit architecture will make everything run a hell of a lot faster (or have the potential to). the algorithms compared to 32-bit are just completely blown away by 64-bit. that was going to be my main point for that but i kinda forgot.
Click to expand...

Anyone who has ever studied Computer Science will tell you that is completely wrong. The algorithms are the same (look up the word). 64-bit implementations of the algorithms can be faster in some situations where you are:

a) Dealing with vast amounts of data. More than 2Gb in memory is about the cutoff

b) Dealing with high precision numbers (although AlitVec and SSE are a better choice here).

What you are thinking of is the IA-64 architecture having certain advantages of IA-32. This is mostly down to a larger number of general purpose registers. This can make some code run faster when re-compiled for 64-bits from 32 but the difference is generally very small, normally around 5%. You'd not even notice this. The Finder would see even less improvement as it is mostly IO limited by disk and network access, neither of which are impacted.
 
robbieduncan said:
64-bit implementations of the algorithms can be faster in some situations where you are:

a) Dealing with vast amounts of data. More than 2Gb in memory is about the cutoff

b) Dealing with high precision numbers (although AlitVec and SSE are a better choice here).

What you are thinking of is the IA-64 architecture having certain advantages of IA-32. This is mostly down to a larger number of general purpose registers.
Click to expand...

And 64bit x86 doubles the number of general-purpose registers when compared to 32bit x86, not to mention SSE-registers. IA64 on the other hand is Itanium, it has nothing to do with 64bit x86-CPU's (the thing we are discussing here)
 
Evangelion said:
And 64bit x86 doubles the number of general-purpose registers when compared to 32bit x86, not to mention SSE-registers. IA64 on the other hand is Itanium, it has nothing to do with 64bit x86-CPU's (the thing we are discussing here)
Click to expand...

My mistake. I was referring to x86-64. I knew Intel tried to rename it from AMD64 to something closer to IA-32 which was their own name for 32-bit x86. Apparently they want us all to call it Intel 64. Anyway as I pointed out above the extra registers are nice, but real world performance is not massively effected by them, especially in a heavily IO dependent app like the Finder.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back