Why would rewriting the Finder be a waste of time?
Because the Finder has features that were impressive for the early 90's, but not for today. Rewriting the Finder in Cocoa just to make those "Cocoa Finder!!!" folks happy is useless. What needs to be done is to reinvent the file management wheel.
If Apple wanted a Cocoa Finder, why didn't they just go ahead and use the NeXT browser, tweaking it to look more like the Finder? Instead, they took the Mac OS Classic Finder and tweaked it to look more like a NeXT app.
Because the Finder has features that were impressive for the early 90's, but not for today. Rewriting the Finder in Cocoa just to make those "Cocoa Finder!!!" folks happy is useless. What needs to be done is to reinvent the file management wheel.
Yeah. And exploit that new hardware coming down the pipe. Alot of the current GUI would have been impressive back in the late 90s. But it's merely buffed up in my mind.
I think Apple's biggest nightmare so far is getting both Carbon and Cocoa to look and feel the same. This hasn't happened yet. Maybe 10.3? I doubt it...but I hope *you* can prove me wrong, moki my boy.
There is nothing to prove. Some things just are.
I develop software for OS X using Carbon for some projects, Cocoa for others. Your assertions are unfortunate.
yea but iTunes has had like 5 times more development time than any other iApp. The closest one to iTunes is iMovie, and that was ported to Cocoa (also became a much better app when this was done)
And what of the speed issues with iTunes, Photoshop, Illustrator, Office and many other ridiculous carbon apps?
If Cocoa is not a magic bullet...what the **** is carbon?
Again, you people are twisting my words...a poorly written Cocoa app exists. A poorly written Carbon exists.
The Cocoa API just offers more for less is what I'm saying...therefore it's better. We'll just have to wait and see what 10.3 will do to close the gap between Carbon and Cocoa...otherwise it'll only widen.
Unless moki has a supar-sekrit 10.3 build, which I doubt, he's in no position to tell Carbon will continue it's evolution at the same speed as Cocoa.
im not on the cocoa/magic bullet train, but i do think that apple will be adding more cocoa code to its lineup, and rightly so.
the speed issues are inherent of the nature of the app. try to make an app that can dynamically resize all your photos and scroll through them at lightning speed without any lag. I will pay good money for it. photoshops image browser is not even close, and i thought they were the experts at pro media programs
The Cocoa API just offers more for less is what I'm saying...therefore it's better. We'll just have to wait and see what 10.3 will do to close the gap between Carbon and Cocoa...otherwise it'll only widen.
Unless moki has a supar-sekrit 10.3 build, which I doubt, he's in no position to tell Carbon will continue it's evolution at the same speed as Cocoa.
One might also say that unless you are a developer with hundreds of thousands of lines of existing code to maintain, you are in no position to state whether moving it to Cocoa makes any sense whatsoever.
Indeed, I can't think of any major applications outside of Apple that made the move from Carbon to Cocoa. You might think there is a good reason for this (which has nothing to do with the viability of the cocoa APIs). Can you name any?
The Cocoa APIs are nice. They also require a *lot* of re-learning in order to utilize them well. Esperanto was nice, but the investment in the English language made transitioning to it not useful. The metric system is undoubtably a superior system or measurement, yet the entrenchment in the US and other countries has made the transition slow at best.
Apple has a very, very strong incentive to keep refining the Carbon APIs: every major third party application uses it. The Carbon and Cocoa APIs are both intended to be permanent APIs that are equal citizens, and indeed there is quite a bit of sharing of code between the two (usually Cocoa calling Carbon, such as for the menus, for QuickTime, etc.)
People should care as much about whether an application is Cocoa or Carbon as they cared whether it was PowerPlant or Toolbox for MacOS 9. Anyone who states that an application should be moved to Cocoa simply for the sake of "making it Cocoa" really just doesn't know what they are talking about.
the speed issues are inherent of the nature of the app. try to make an app that can dynamically resize all your photos and scroll through them at lightning speed without any lag. I will pay good money for it. photoshops image browser is not even close, and i thought they were the experts at pro media programs
Really? Someone should tell that to the developers or iView Media and iView Media Pro:
This is a very fast program, and it is cross-platform. It handles a large number of images much more adroitly than iPhoto does... and it is a Carbon application.
Use the right tool for the job. Sometimes it will be Carbon. Sometimes it will be Cocoa. Don't tell a construction worker he should be using a hammer when what he really needs is a saw.
Anyone who states that an application should be moved to Cocoa simply for the sake of "making it Cocoa" really just doesn't know what they are talking about.
Nobody made such a statement. Well...at least I didn't.
My statement was very clear ... but anyone who wishes to twist it into a "making it Cocoa for the sake of making it Cocoa" statement can go ahead, but he would be fooling himself.
This is a very fast program, and it is cross-platform. It handles a large number of images much more adroitly than iPhoto does... and it is a Carbon application.
Use the right tool for the job. Sometimes it will be Carbon. Sometimes it will be Cocoa. Don't tell a construction worker he should be using a hammer when what he really needs is a saw.
Indeed. This app is only way to manage thousands of images on the Mac. Fast as hell.
Nobody made such a statement. Well...at least I didn't.
My statement was very clear ... but anyone who wishes to twist it into a "making it Cocoa for the sake of making it Cocoa" statement can go ahead, but he would be fooling himself.
Enumerate, exactly, what Apple would gain by making the Finder Cocoa, then? (other than throwing away hundreds of thousands of man-hours that are invested in the current Carbon Finder)
Enumerate, exactly, what Apple would gain by making the Finder Cocoa, then? (other than throwing away hundreds of thousands of man-hours that are invested in the current Carbon Finder)
Whether the Cocoa API offers more for less depends on what you want. Frameworks are great at solving problems that they anticipate, and really, really annoying if you find yourself working around or against them. APIs like Carbon work the other way 'round. If nothing else this complementary relationship is the best available argument for Apple keeping both options available: When Cocoa does not offer what you need, use Carbon. And vice versa.
This decision does not have to be made on a per-application basis. Even the fact that this discussion asserts a concrete distinction between a "Cocoa application" and a "Carbon application" essentially misses the point, as the two can be commingled freely. It gets even more interesting than that: If what I have heard is true, then Finder is a proof-of-concept for CodeWarrior's port of PowerPlant to Carbon, and it has improved as PowerPlant has improved. This, too, is critical for Apple, as PowerPlant Mac applications are common. Now that PowerPlant has gone cross-platform, it's become an even more appealing option for developers. So Apple had to make sure it was working well, even though this meant that the Finder would be rather shaky for a while. I digress; the point is that Apple also has to be concerned with the viability of third-party class libraries.
As to the merging of Carbon and Cocoa over CoreFoundation (note: This is not necessarily porting Cocoa to Carbon, it's porting them both to CoreFoundation, and having Cocoa call Carbon when that's the best way to accomplish that), this has been a goal repeatedly stressed by Apple, and which Apple has come closer to achieving with each release of OS X. If you want to postulate that Apple will ditch Carbon, you'll have to argue against the direction Apple has taken since they announced OS X, and you'll have to argue for a reason for Apple to abandon a developer technology, given the effect that would have on their developers (you have to consider that Apple's developer base remembers Apple's woeful history here, this concerns more than just the abstract effect of a platform publisher dropping an API).
The unification of Carbon and Cocoa (and who ever else comes to the party) serves not only to make OS X that much more consistent within itself, but also to reduce Apple's workload: A bug fix in CoreFoundation affects both Carbon and Cocoa.
It's pretty obvious why Apple's doing a lot of application development in Cocoa: They're one company trying to do a lot of things at once; they're developing all-new, more-or-less conventional applications in many cases; and they don't really care about whether the apps run on anything other than Mac OS X. That's about the best case for Cocoa. It does not, however, mean that it's in everyone's interest to do what Apple has done.
Mark my words: Carbon will stick around, Carbon and Cocoa will merge over CoreFoundation, and, combined with the other development environments Apple offers (BSD, Java, AppleScript), it will have just about all of the bases covered as far as developer needs are concerned.
I've surmised that iPhoto is slow because (unlike iTunes which begins in the playlist where you left off in most cases) it open in the entire iPhoto library each time you start the app and loads the preview images into a cache all at once, and is constantly dealing with your photos in one huge chunk of cache (in RAM or spilling into swap space). From what I can tell, it's not threaded that much, and it deals with all those little images at once.
Apple would move the Finder to Cocoa for two reasons:
1. they want to add various Finder pieces/objects/frameworks to other apps as well as the Finder, and...
2. to speed up future development of the Finder, which of course assumes that building on a Cocoa foundation which is mostly new is faster than building on the established Carbon foundation despite its relative maturity in this specific case.
a) Full acceleration of 2d drawing on programmable video cards ( that is, DX9 capable cards ).
b) 64bit support for the 970. I think that the key application for 64bit, at release, will be the ability for the kernel to map another machines memory into the address space of an app. That means that a cluster of 970's can run an app across all the machines transparently. The developer would want to write for this case, as accessing memory over a network would be terribly slow. This isnt easily feasible with a 32bit address space.
I read it. You don't know what you're talking about.
edit: misread your post...
I don't know what I'm talking about?
I hate the current Finder...it's in need of a complete overhaul. It needs speed optimizations, it needs new features, it needs lots of things. I think it would be better for Apple to rewrite the whole thing...wipe the slate clean. And if they're going to rewrite, they might as well rewrite in Cocoa like they've been doing. At least we'll get a consistent toolbar, some drawers (if the need arises), anti-aliased text for text clippings...no need for Cocoa wrappers when adding Cocoa frameworks functionalities to the Finder...etc. etc.
Apple could tack on features and struggle to optimize the current codebase but it doesn't seem to be leading anywhere judging from the 2 big point releases and 15 small point releases.
Maybe I don't know what I'm talking about but...I'm the customer here and if the Finder doesn't improve in 10.3, I may start looking else where.
Comments
Originally posted by kim kap sol
Why would rewriting the Finder be a waste of time?
Because the Finder has features that were impressive for the early 90's, but not for today. Rewriting the Finder in Cocoa just to make those "Cocoa Finder!!!" folks happy is useless. What needs to be done is to reinvent the file management wheel.
If Apple wanted a Cocoa Finder, why didn't they just go ahead and use the NeXT browser, tweaking it to look more like the Finder? Instead, they took the Mac OS Classic Finder and tweaked it to look more like a NeXT app.
Because the Finder has features that were impressive for the early 90's, but not for today. Rewriting the Finder in Cocoa just to make those "Cocoa Finder!!!" folks happy is useless. What needs to be done is to reinvent the file management wheel.
Yeah. And exploit that new hardware coming down the pipe. Alot of the current GUI would have been impressive back in the late 90s. But it's merely buffed up in my mind.
Where's the Finder revolution Apple?
Lemon Bon Bon
Originally posted by kim kap sol
I think Apple's biggest nightmare so far is getting both Carbon and Cocoa to look and feel the same. This hasn't happened yet. Maybe 10.3? I doubt it...but I hope *you* can prove me wrong, moki my boy.
There is nothing to prove. Some things just are.
I develop software for OS X using Carbon for some projects, Cocoa for others. Your assertions are unfortunate.
Originally posted by Imergingenious
yea but iTunes has had like 5 times more development time than any other iApp. The closest one to iTunes is iMovie, and that was ported to Cocoa (also became a much better app when this was done)
And what of the speed issues in iCal/iPhoto?
Again, Cocoa is not a magic bullet.
Originally posted by moki
And what of the speed issues in iCal/iPhoto?
Again, Cocoa is not a magic bullet.
And what of the speed issues with iTunes, Photoshop, Illustrator, Office and many other ridiculous carbon apps?
If Cocoa is not a magic bullet...what the **** is carbon?
Again, you people are twisting my words...a poorly written Cocoa app exists. A poorly written Carbon exists.
The Cocoa API just offers more for less is what I'm saying...therefore it's better. We'll just have to wait and see what 10.3 will do to close the gap between Carbon and Cocoa...otherwise it'll only widen.
Unless moki has a supar-sekrit 10.3 build, which I doubt, he's in no position to tell Carbon will continue it's evolution at the same speed as Cocoa.
the speed issues are inherent of the nature of the app. try to make an app that can dynamically resize all your photos and scroll through them at lightning speed without any lag. I will pay good money for it. photoshops image browser is not even close, and i thought they were the experts at pro media programs
Originally posted by kim kap sol
The Cocoa API just offers more for less is what I'm saying...therefore it's better. We'll just have to wait and see what 10.3 will do to close the gap between Carbon and Cocoa...otherwise it'll only widen.
Unless moki has a supar-sekrit 10.3 build, which I doubt, he's in no position to tell Carbon will continue it's evolution at the same speed as Cocoa.
One might also say that unless you are a developer with hundreds of thousands of lines of existing code to maintain, you are in no position to state whether moving it to Cocoa makes any sense whatsoever.
Indeed, I can't think of any major applications outside of Apple that made the move from Carbon to Cocoa. You might think there is a good reason for this (which has nothing to do with the viability of the cocoa APIs). Can you name any?
The Cocoa APIs are nice. They also require a *lot* of re-learning in order to utilize them well. Esperanto was nice, but the investment in the English language made transitioning to it not useful. The metric system is undoubtably a superior system or measurement, yet the entrenchment in the US and other countries has made the transition slow at best.
Apple has a very, very strong incentive to keep refining the Carbon APIs: every major third party application uses it. The Carbon and Cocoa APIs are both intended to be permanent APIs that are equal citizens, and indeed there is quite a bit of sharing of code between the two (usually Cocoa calling Carbon, such as for the menus, for QuickTime, etc.)
People should care as much about whether an application is Cocoa or Carbon as they cared whether it was PowerPlant or Toolbox for MacOS 9. Anyone who states that an application should be moved to Cocoa simply for the sake of "making it Cocoa" really just doesn't know what they are talking about.
Originally posted by Imergingenious
the speed issues are inherent of the nature of the app. try to make an app that can dynamically resize all your photos and scroll through them at lightning speed without any lag. I will pay good money for it. photoshops image browser is not even close, and i thought they were the experts at pro media programs
Really? Someone should tell that to the developers or iView Media and iView Media Pro:
http://www.iview-multimedia.com/
This is a very fast program, and it is cross-platform. It handles a large number of images much more adroitly than iPhoto does... and it is a Carbon application.
Use the right tool for the job. Sometimes it will be Carbon. Sometimes it will be Cocoa. Don't tell a construction worker he should be using a hammer when what he really needs is a saw.
Originally posted by moki
Anyone who states that an application should be moved to Cocoa simply for the sake of "making it Cocoa" really just doesn't know what they are talking about.
Nobody made such a statement. Well...at least I didn't.
My statement was very clear ... but anyone who wishes to twist it into a "making it Cocoa for the sake of making it Cocoa" statement can go ahead, but he would be fooling himself.
Originally posted by moki
Really? Someone should tell that to the developers or iView Media and iView Media Pro:
http://www.iview-multimedia.com/
This is a very fast program, and it is cross-platform. It handles a large number of images much more adroitly than iPhoto does... and it is a Carbon application.
Use the right tool for the job. Sometimes it will be Carbon. Sometimes it will be Cocoa. Don't tell a construction worker he should be using a hammer when what he really needs is a saw.
Indeed. This app is only way to manage thousands of images on the Mac. Fast as hell.
Why is iPhoto so damn slow?
Originally posted by kim kap sol
Nobody made such a statement. Well...at least I didn't.
My statement was very clear ... but anyone who wishes to twist it into a "making it Cocoa for the sake of making it Cocoa" statement can go ahead, but he would be fooling himself.
Enumerate, exactly, what Apple would gain by making the Finder Cocoa, then? (other than throwing away hundreds of thousands of man-hours that are invested in the current Carbon Finder)
Originally posted by moki
Enumerate, exactly, what Apple would gain by making the Finder Cocoa, then? (other than throwing away hundreds of thousands of man-hours that are invested in the current Carbon Finder)
*yawn*
Go read the beginning of this thread.
This decision does not have to be made on a per-application basis. Even the fact that this discussion asserts a concrete distinction between a "Cocoa application" and a "Carbon application" essentially misses the point, as the two can be commingled freely. It gets even more interesting than that: If what I have heard is true, then Finder is a proof-of-concept for CodeWarrior's port of PowerPlant to Carbon, and it has improved as PowerPlant has improved. This, too, is critical for Apple, as PowerPlant Mac applications are common. Now that PowerPlant has gone cross-platform, it's become an even more appealing option for developers. So Apple had to make sure it was working well, even though this meant that the Finder would be rather shaky for a while. I digress; the point is that Apple also has to be concerned with the viability of third-party class libraries.
As to the merging of Carbon and Cocoa over CoreFoundation (note: This is not necessarily porting Cocoa to Carbon, it's porting them both to CoreFoundation, and having Cocoa call Carbon when that's the best way to accomplish that), this has been a goal repeatedly stressed by Apple, and which Apple has come closer to achieving with each release of OS X. If you want to postulate that Apple will ditch Carbon, you'll have to argue against the direction Apple has taken since they announced OS X, and you'll have to argue for a reason for Apple to abandon a developer technology, given the effect that would have on their developers (you have to consider that Apple's developer base remembers Apple's woeful history here, this concerns more than just the abstract effect of a platform publisher dropping an API).
The unification of Carbon and Cocoa (and who ever else comes to the party) serves not only to make OS X that much more consistent within itself, but also to reduce Apple's workload: A bug fix in CoreFoundation affects both Carbon and Cocoa.
It's pretty obvious why Apple's doing a lot of application development in Cocoa: They're one company trying to do a lot of things at once; they're developing all-new, more-or-less conventional applications in many cases; and they don't really care about whether the apps run on anything other than Mac OS X. That's about the best case for Cocoa. It does not, however, mean that it's in everyone's interest to do what Apple has done.
Mark my words: Carbon will stick around, Carbon and Cocoa will merge over CoreFoundation, and, combined with the other development environments Apple offers (BSD, Java, AppleScript), it will have just about all of the bases covered as far as developer needs are concerned.
1. they want to add various Finder pieces/objects/frameworks to other apps as well as the Finder, and...
2. to speed up future development of the Finder, which of course assumes that building on a Cocoa foundation which is mostly new is faster than building on the established Carbon foundation despite its relative maturity in this specific case.
a) Full acceleration of 2d drawing on programmable video cards ( that is, DX9 capable cards ).
b) 64bit support for the 970. I think that the key application for 64bit, at release, will be the ability for the kernel to map another machines memory into the address space of an app. That means that a cluster of 970's can run an app across all the machines transparently. The developer would want to write for this case, as accessing memory over a network would be terribly slow. This isnt easily feasible with a 32bit address space.
Originally posted by kim kap sol
*yawn*
Go read the beginning of this thread.
I read it. You don't know what you're talking about.
Originally posted by moki
I read it. You don't know what you're talking about.
edit: misread your post...
I don't know what I'm talking about?
I hate the current Finder...it's in need of a complete overhaul. It needs speed optimizations, it needs new features, it needs lots of things. I think it would be better for Apple to rewrite the whole thing...wipe the slate clean. And if they're going to rewrite, they might as well rewrite in Cocoa like they've been doing. At least we'll get a consistent toolbar, some drawers (if the need arises), anti-aliased text for text clippings...no need for Cocoa wrappers when adding Cocoa frameworks functionalities to the Finder...etc. etc.
Apple could tack on features and struggle to optimize the current codebase but it doesn't seem to be leading anywhere judging from the 2 big point releases and 15 small point releases.
Maybe I don't know what I'm talking about but...I'm the customer here and if the Finder doesn't improve in 10.3, I may start looking else where.