The NeXTies love Cocoa. Cocoa is their baby. Steve LOVES Cocoa. Avi loves Cocoa.
Carbon will be left by the wayside, bit by bit over the next 3-4 years, as Apple implements Cocoa-only advantages to lure them from their Carbon codebase.
Apple wants EVERYONE to use Cocoa. They are giving lip service to the developers regarding Carbon just to keep them in line. As they implement "gotta-have-it" things in Cocoa, they will lure more and more developers to it until they have who they want on board. Then Carbon dies, just as Mac OS 9 has.
It is NOT about compatibility. It is about what Apple (Steve, et al) want. Carbon was forced on them by developers who refused to rewrite code from scratch for OS X. Steve will not let them get away with that one day longer than he has to.
a) more and more cocoa only stuff is now is carbon
b) adobe is not going to make cocoa photshop which pretty much ends the debate of carbon going by the "wayside"
a)
b) Carbon isn't going 'the wayside'...it just won't get improved. Apple would rather just keep improving one framework...and Cocoa is getting all the attention.
I'm sick of hearing people saying there are no difference between Carbon and Cocoa. I'm sick of hearing people say that Carbon and Cocoa are merging. They're not...you can have Carbon events in inside a Cocoa app but the two aren't merging.
Cocoa is the future. Carbon will stay but won't get improved.
PhotoShop is, if I recall, mostly a "C/C++" application.
The bits of Carbon that are needed for X functionality are a relatively small percentage of the code.
Cocoa is a superset of "C," and now includes "C++" language availability.
When the Cocoa aspects offer improved functionality or performance over the carbon portions of the code, Adobe will switch to Cocoa. It will not happen overnight, but it will happen, I predict.
Cocoa is too easy, too rapid to develop in, to ignore in the long run, I believe.
1. No. Carbon is NOT "better" or "worse" than Cocoa. It is NOT "less native" or "more native" than Cocoa. It is not "under-privileged" in comparison to Cocoa.
2. The journaled filesystem has been here since 10.2.2 (10.2.3?), but what we need is a completely new one, or a port of a good one (like XFS or ReiserFS). It seems to me like people don't even realize this: HFS+ is SLOW! Mac OS X could be so much faster with a better file system.
3. Surely Panther will feature an updated GCC, which will bring lots of performance, too.
4. Brushed metal everywhere is bullcrap for a simple reason: programmers will be pissed off once again because they'd have to adapt their interfaces, AGAIN. Have you seen NSToolbars in Brushed Metal interfaces? Then you know why Apple avoids that.
5. iAnything means "NOT pro, but consumer". Thus, "iPhoto Professional" will surely not be the name. Also, I can't think of any reason whatsoever for Apple to release a professional image management solution.
6. I don't believe in a Cocoa Finder, UNLESS it'll be a real new thing (which we need anyway), like the "Metadata Finder". The Metadata Finder, of course, would make iTunes and iPhoto more or less obsolete, as their main feature is file management. Playing MP3s, burning CDs and simple photo management doesn't require applications like iTunes or iPhoto.
Also, I find it funny that with every single major Mac OS X update, Cocoa Finder rumors keep coming up. With 10.1, with 10.2, and now, with 10.3. The current Finder's interface isn't really good (worse yet, Path Finder copies almost all of its negative aspects), though.
7. AppleWorks is dead, people. AppleWorks has a presentation module which just got rendered useless with the release of Keynote. Apple will replace AppleWorks components with single applications, as has been their interface model since years (integrated interfaces are a bad idea).
8. Revamping the Dock? Right now, the Dock is cool, but not very clever.
9. Not sure what your definition of "WMP" is.
10. Rendezvous is fine. Just now, it's slowly taking off with Linux systems (Mandrake 9.1 includes a ZeroConf implementation). Slooooowly, applications will come up. And hopefully, there'll be a Windows implementation, too.
11. What's wrong with Grap.app?
12. An audio suite? I dunno. Logic seems to be alright.
6. I don't believe in a Cocoa Finder, UNLESS it'll be a real new thing (which we need anyway), like the "Metadata Finder". The Metadata Finder, of course, would make iTunes and iPhoto more or less obsolete, as their main feature is file management. Playing MP3s, burning CDs and simple photo management doesn't require applications like iTunes or iPhoto.
When you have over 2,000 CDs and each individual CD is a playlist you start to see how amazing and wonderful iTunes is.
When you have over 2,000 CDs and each individual CD is a playlist you start to see how amazing and wonderful iTunes is.
He's saying that with a good metadata support in the Finder, iTunes won't be *as* necessary for music browsing. I'm sure iTunes will still remain the ideal browsing method, but you'll be able to achieve close to the same type browsing via the Finder if you wanted to.
Apple is constantly improving Cocoa...and Carbon is always a few steps behind. The Finder with a Cocoa interface would be in tune with what Apple has been doing in the past year: moving their software to Cocoa.
please provide a list of applications cocoa-ized by apple from carbon?
Apple is pushing developers to use Cocoa at this point. Carbon was great for OS 9 apps that needed porting to OS X...but Apple makes it clear that new projects or rewrites should be in Cocoa.
no matter how apple is pushing, developers are not willing to re invent the wheel to do the same thing again. yes, new application may be written in cocoa, but not the one has been done. why "may be"? it will depend on the user base. if one developer still has large os 8/9 customer base, i bet s/he will still use carbon, not cocoa to develope new app.
The Finder is in bad shape. Very bad shape. A rewrite in Cocoa would probably solve LOTS of problems as opposed to trying to heal a fatally wounded Carbon Finder...not because it's Cocoa, but because a rewrite would allow Apple to start fresh with things like a a new filesystem in mind as opposed to tacking it on as a hack to the existing Finder.
many people keep saying Finder in bad shape, well, it might be true in certain aspects, but this can not be translated into a cocoa Finder. from practical software developmental point of view, apple should not have two Finders, carbon and cocoa. it would be stupid to double QA testing work.
But let's face it folks...Cocoa allows for toolbars, drawers and quite a few neat-o things coming in 10.3 that won't be available to Carbon developers. Carbon and Cocoa may be unifying more and more but Apple says Cocoa should be used from now on, so why not bite the bullet and follow Apple's words of wisdom. They know best as to what Cocoa is and will become.
war here is not carbon vs cocoa, but os x vs os x-, which to improve os x. no doubts about it, this undertaking has been great drill already, now, before the platform gets a firm footage, people are asking for reshape the plan. it is not good.
i am still puzzled by the decision by apple on cocoa api. steve and avi have been in software business for quite long, did not they realize that rewrite a million lines of code of an existing application is a hugh undertaking? it just likes to dump english or any other earth language and instead, to adopt mars' language.
people also said that eventually every one will converge on cocoa. i seriously doubt it. i have 50k lines of code module and would like to rewrite it in a better way and clean way, my QA department fighted to stop it fiercly. so don't expect adobe, microsoft, or other bigger developers to rewrite their big applications. it is just unpractical.
Originally posted by anakin1992 please provide a list of applications cocoa-ized by apple from carbon?
DVD Studio Pro 2, for example.
Quote:
no matter how apple is pushing, developers are not willing to re invent the wheel to do the same thing again. yes, new application may be written in cocoa, but not the one has been done. why "may be"? it will depend on the user base. if one developer still has large os 8/9 customer base, i bet s/he will still use carbon, not cocoa to develope new app.
Agreed, mostly.
Quote:
many people keep saying Finder in bad shape, well, it might be true in certain aspects, but this can not be translated into a cocoa Finder.
Agreed.
Quote:
from practical software developmental point of view, apple should not have two Finders, carbon and cocoa. it would be stupid to double QA testing work.
I don't see how an application that's in development stage requires QA. A finished Cocoa Finder would of course replace the current one.
Quote:
i am still puzzled by the decision by apple on cocoa api.
FYI, AppleWorks got a minor update this month. It even comes in a new box which is similar to the new iLife apps and Keynote boxes. Check it out at AppleStore
i know there are some applications being ported over to cocoa by apple, but the number is quite limited to very small range.
Quote:
I don't see how an application that's in development stage requires QA. A finished Cocoa Finder would of course replace the current one.
yes, when a new feature is developed, QA is not involved. once design and unit testing are done, then QA is in. but designer is not off the hook.
to my understanding, current Finder is implemented in carbon and Finder is one of functionalities in OS X (let us just talke about jaguar alone for simplicity), while each of features in OS X has to be QA-ed indiviudally first and then integrated. now, you change, completely, on Finder and then you tell QA to redo the testing. i guess it is ok to ask them, but the problem is that you have to make sure the nice coordination on integration among various groups working on different features. if it is a standalone application, it might be easier. but dreadful thing happens if one thing changes everything else is affected. in addition, if there are couple of versions of the same features, dumping one for another is not easily being done.
i used to have just one branch of code base. but soon, various branches spawn because of new features coming in. for a smaller project, it is no brainer at all. for a big and collaborated project, it is nightmare to integrate various parts or modules. integration is only the first step, then comes to QA, then back to designer for bug fix then integration, then QA... it is an endless working cycles. so, i normally include QA into the design cycle and i understand that we could have various opinion and expereinces.
finally, a product is released, but that cycle is still there: bug report and fix and QA and on and on. suddently, a group wants to revamp what it has done, let us Finder, and have a completely new thing. basically, this causes us to the square 1.
Quote:
What decision?
the decision to use cocoa when they announced the new mac OS. years ago, (20 or 30 years ago?)linguists invented a univeral language which overcame every bad aspect of all the languages on this planet and hoped it to adopted worldwide. looking around ourselves now, who is using it? english is dominant now, at least in computing and scientific areas, though in pure linguistic point of view english is no better than indian native language at all.
i guess what i tried to point out was that no matter what technology there is, if it can not, practically, solve the problems for your customer and facilitate their work, then it is useless. in apple's case, the customers are adobe, microsoft, and others.
FYI, AppleWorks got a minor update this month. It even comes in a new box which is similar to the new iLife apps and Keynote boxes. Check it out at AppleStore
to my understanding, current Finder is implemented in carbon and Finder is one of functionalities in OS X (let us just talke about jaguar alone for simplicity), while each of features in OS X has to be QA-ed indiviudally first and then integrated. now, you change, completely, on Finder and then you tell QA to redo the testing. i guess it is ok to ask them, but the problem is that you have to make sure the nice coordination on integration among various groups working on different features. if it is a standalone application, it might be easier. but dreadful thing happens if one thing changes everything else is affected.
For me, the Finder is just (or should be) a GUI for file management. Have you tried Path Finder? It does almost all the Finder does, and more (Converting Pictures, Mounting Disk Images, ...). It's written in Cocoa, looks almost like the Finder, and obviously didn't require any kind of source code from the "real" Finder. The Finder shouldn't be all that complex, and thus, QA testing shouldn't be, either.
Quote:
the decision to use cocoa when they announced the new mac OS.
You mean the decision to buy NeXT and use their operating system base? It was a damn right decision.
Quote:
years ago, (20 or 30 years ago?)linguists invented a univeral language which overcame every bad aspects of all the languages on this planet and hoped it to adopted worldwide. looking around ourselves now, who is using it? english is dominant now, at least in computing and scientific areas, though in pure linguistic point of view english is no better than indian native language at all.
If you mean Esperanto, that was 150 years ago. It didn't work out because English just worked already
i know there are some applications being ported over to cocoa by apple, but the number is quite limited to very small range.
No, it's definitely a direction at Apple. And not so small.
just a few Carbon to Cocoa rewrites
iMovie 2 --> iMovie 3
DVD Studio Pro --> DVD Studio Pro 2
Java 1.3 --> Java 1.4
iDVD --> iDVD 2
Apple System Profiler (10.1) --> Apple System Profiler (10.2)
Help Viewer (10.1) --> Help Viewer (10.2)
AppleScript Editor (10.1) --> Script Editor Beta
And so on.
If anything, the trend seems to be increasing. And of course, practically all new Apple apps are Cocoa.
The Carbon vs. Cocoa debate, when shifted away from its most tiresome, black and white form ("Carbon apps suck! Make it in Cocoa!" "Cocoa apps are slow and suck!") is kind of interesting. Apple has insisted Carbon and Cocoa will be equal citizens, but at the same time it's clear they are moving as much app development over to Cocoa as possible. I actually wouldn't be surprised to hear if there are considerable Cocoa chunks in the Panther Finder.
Question is, can Apple afford to support parallel development in two APIs as new features are added? In the short-term future, sure. It's the long-term future that's more of a mystery.
I'll be interested whether WWDC clears up some of the haze over the future of Carbon vs. Cocoa development.
For me, the Finder is just (or should be) a GUI for file management. [snipped...]
yes, but behind the door, the mechanism to provide a way to relay apple events between the Finder and an Application is done differently, though i hope not, between cocoa and carbon: cocoa is done in an ood way and i don't think carbon uses the same way.
the path Finder is the same as the Finder? i doubt it, but since i never used it before, i can not say much. there is a way to quite the Finder in jaguar. then can you start the Path Finder? is this the Path Finder has to work with the Finder first? anyone knows about it? please post your opinions and thanks ahead.
No, it's definitely a direction at Apple. And not so small.
just a few Carbon to Cocoa rewrites
iMovie 2 --> iMovie 3
DVD Studio Pro --> DVD Studio Pro 3
Java 1.3 --> Java 1.4
iDVD --> iDVD 2
Apple System Profiler (10.1) --> Help Viewer (10.2)
Help Viewer (10.1) --> Help Viewer (10.2)
AppleScript Editor (10.1) --> Script Editor Beta
And so on.
many thanks for the info. i only knew couple of them. one example makes me quite wonder: if i have an old java application on java 1.3, now in order to use java 1.4, do i have to rework my application to fit java 1.4? normally, i would continue to use java 1.3. but the problem occurs when apple will only update on java 1.4 on bug fix or new features, then i have to be forced to do things in java 1.4. it is ok for once to do it. what about sometime later apple finds a new way to do java on mac os x, what am i going to do again?
Quote:
If anything, the trend seems to be increasing. And of course, practically all new Apple apps are Cocoa.
yeah, it makes much sense to have complete new application in cocoa. by new, i meant, no reuse on the old code. not just for apple, every one else should use cocoa for new app. but the question remains: are those old apps, such as word, excell, ps, etc to be written in cocoa or not? another interesting question will be: are there any new apps that are going to replace those old apps in carbon, such as word, etc?
Quote:
The Carbon vs. Cocoa debate, when shifted away from its most tiresome, black and white form ("Carbon apps suck! Make it in Cocoa!" "Cocoa apps are slow and suck!") is kind of interesting. Apple has insisted Carbon and Cocoa will be equal citizens, but at the same time it's clear they are moving as much app development over to Cocoa as possible. I actually wouldn't be surprised to hear if there are considerable Cocoa chunks in the Panther Finder.
i am not against using cocoa or carbon, as long as it works, i am fine. but what do customers think? if new Finder in panther is cooked in cocoa, what are the effects this change will bring to the behaviors on the interaction between the Finder and application?
Quote:
Question is, can Apple afford to support parallel development in two APIs as new features are added? In the short-term future, sure. It's the long-term future that's more of a mystery.
the only ways i think of that apple will be ok are that there will be a new technology, either hardware or software, rendering both carbon and cocoa as usless or at least not efficient any more; or, apple decides to dump all the old buddies, like adobe, microsoft, etc and dose every thing by itself.
many thanks for the info. i only knew couple of them. one example makes me quite wonder: if i have an old java application on java 1.3, now in order to use java 1.4, do i have to rework my application to fit java 1.4? normally, i would continue to use java 1.3. but the problem occurs when apple will only update on java 1.4 on bug fix or new features, then i have to be forced to do things in java 1.4. it is ok for once to do it. what about sometime later apple finds a new way to do java on mac os x, what am i going to do again?
What incompatibilities there are have everything to do with the changes from Java 1.3 to Java 1.4.1 and Apple's as-yet-incomplete implementation of 1.4.1. The move from Carbon to Cocoa underneath should have absolutely no effect on compatibility. What it does is reduce the number of man-hours required for design, coding and testing, and the number of lines of code that can introduce bugs. That's why Apple's moving so much development to Cocoa: They can get more done in less time with fewer programmers, and with fewer lines of code.
Quote:
yeah, it makes much sense to have complete new application in cocoa. by new, i meant, no reuse on the old code. not just for apple, every one else should use cocoa for new app. but the question remains: are those old apps, such as word, excell, ps, etc to be written in cocoa or not? another interesting question will be: are there any new apps that are going to replace those old apps in carbon, such as word, etc?
One persistent fallacy in this thread is that an application has to be Carbon or Cocoa. Nothing at all prevents a vendor with a big C++ app linked to Carbon from redoing the GUI in IB and the view layer(s) in Cocoa, and linking against a Carbon back end. The issues are: How well-factored is the code, how quickly can the developers get up to speed (Apple argues, from their own experience, that this curve is relatively low), and how many advantages can be gained from linking to a framework like Cocoa and (optionally) from a lean, dynamic language like Objective-C.
In fact, any Cocoa app that deals with QuickTime is going to have a healthy amount of Carbon code in it.
Quote:
i am not against using cocoa or carbon, as long as it works, i am fine. but what do customers think? if new Finder in panther is cooked in cocoa, what are the effects this change will bring to the behaviors on the interaction between the Finder and application?
Ideally, the customers shouldn't notice. The decision to use an API should be a development decision. In practice, Cocoa allows a few developers to write a very slick application with comparatively few lines of code, so Cocoa apps are often considered more polished just because apps get all that behavior for next to nothing. This is not intrinsic, of course, because Mac OS Toolbox apps achieved high levels of polish despite being on an API more primitive than Carbon — it just required a lot of elbow grease to get there.
Along these lines, A Cocoa Finder will make little to no difference to any other applications (whose interactions with the Finder are pretty minimal as it is). They pop the same windows, get the same events, and so forth. They handle these things differently internally, but what they do internally is irrelevant. Currently, Finder forwards most events to an application called System Events. If that doesn't change, nobody will notice whether Apple recodes the Finder in Objective-C/Cocoa, or in pure Java.
(This assumes that Apple doesn't intend to completely reinvent the Finder, rather than simply moving the existing Finder to Cocoa. In that case, the reinvention would be what sparked the change, since it would be different even if Apple had kept it a Carbon app.)
Quote:
the only ways i think of that apple will be ok are that there will be a new technology, either hardware or software, rendering both carbon and cocoa as usless or at least not efficient any more; or, apple decides to dump all the old buddies, like adobe, microsoft, etc and dose every thing by itself.
Why?! Carbon suffices for some cross-platform and old-school Macintosh developers, and for apps like Ambrosia's Snapz Pro that are better served with a low-level API. Cocoa brings over all the old NeXT applications easily and provides a very attractive way to develop Mac applications, especially for small developers. Java brings in a whole other audience as well. None of these APIs are going to go anywhere, and none of them are being neglected. In fact, Apple has been hard at work unifying them over CoreFoundation. Cocoa and Carbon and C and C++ and Objective-C can be commingled freely, and Python and Java and AppleScript can talk to them and be linked to them. This integration is getting tighter and more complete with every release. There's no need for anything new; if something new comes along (Microsoft's .NET?) it can be built on top of the same Foundation that the rest are, and join the party.
The real issue here is that the final appearance, reliability, performance and polish of an application is up to the developers, not the API (although the language and API chosen will help or hinder these goals variously — it's the developer's job to pick the most appropriate ones). Whether it's a Cocoa app, or Carbon, or Java, or RealBasic, or AppleScript Studio, or what-have-you should be completely transparent to the end user. In the end, a Mac application is a Mac application; if it isn't, the developers didn't do their jobs.
Comments
Carbon will be left by the wayside, bit by bit over the next 3-4 years, as Apple implements Cocoa-only advantages to lure them from their Carbon codebase.
Apple wants EVERYONE to use Cocoa. They are giving lip service to the developers regarding Carbon just to keep them in line. As they implement "gotta-have-it" things in Cocoa, they will lure more and more developers to it until they have who they want on board. Then Carbon dies, just as Mac OS 9 has.
It is NOT about compatibility. It is about what Apple (Steve, et al) want. Carbon was forced on them by developers who refused to rewrite code from scratch for OS X. Steve will not let them get away with that one day longer than he has to.
b) adobe is not going to make cocoa photshop which pretty much ends the debate of carbon going by the "wayside"
Originally posted by keyboardf12
a) more and more cocoa only stuff is now is carbon
b) adobe is not going to make cocoa photshop which pretty much ends the debate of carbon going by the "wayside"
a)
b) Carbon isn't going 'the wayside'...it just won't get improved. Apple would rather just keep improving one framework...and Cocoa is getting all the attention.
I'm sick of hearing people saying there are no difference between Carbon and Cocoa. I'm sick of hearing people say that Carbon and Cocoa are merging. They're not...you can have Carbon events in inside a Cocoa app but the two aren't merging.
Cocoa is the future. Carbon will stay but won't get improved.
End of ****ing story.
carbon will be improved as long as adobe needs it around.
end of this $%% story.
The bits of Carbon that are needed for X functionality are a relatively small percentage of the code.
Cocoa is a superset of "C," and now includes "C++" language availability.
When the Cocoa aspects offer improved functionality or performance over the carbon portions of the code, Adobe will switch to Cocoa. It will not happen overnight, but it will happen, I predict.
Cocoa is too easy, too rapid to develop in, to ignore in the long run, I believe.
2. The journaled filesystem has been here since 10.2.2 (10.2.3?), but what we need is a completely new one, or a port of a good one (like XFS or ReiserFS). It seems to me like people don't even realize this: HFS+ is SLOW! Mac OS X could be so much faster with a better file system.
3. Surely Panther will feature an updated GCC, which will bring lots of performance, too.
4. Brushed metal everywhere is bullcrap for a simple reason: programmers will be pissed off once again because they'd have to adapt their interfaces, AGAIN. Have you seen NSToolbars in Brushed Metal interfaces? Then you know why Apple avoids that.
5. iAnything means "NOT pro, but consumer". Thus, "iPhoto Professional" will surely not be the name. Also, I can't think of any reason whatsoever for Apple to release a professional image management solution.
6. I don't believe in a Cocoa Finder, UNLESS it'll be a real new thing (which we need anyway), like the "Metadata Finder". The Metadata Finder, of course, would make iTunes and iPhoto more or less obsolete, as their main feature is file management. Playing MP3s, burning CDs and simple photo management doesn't require applications like iTunes or iPhoto.
Also, I find it funny that with every single major Mac OS X update, Cocoa Finder rumors keep coming up. With 10.1, with 10.2, and now, with 10.3. The current Finder's interface isn't really good (worse yet, Path Finder copies almost all of its negative aspects), though.
7. AppleWorks is dead, people. AppleWorks has a presentation module which just got rendered useless with the release of Keynote. Apple will replace AppleWorks components with single applications, as has been their interface model since years (integrated interfaces are a bad idea).
8. Revamping the Dock? Right now, the Dock is cool, but not very clever.
9. Not sure what your definition of "WMP" is.
10. Rendezvous is fine. Just now, it's slowly taking off with Linux systems (Mandrake 9.1 includes a ZeroConf implementation). Slooooowly, applications will come up. And hopefully, there'll be a Windows implementation, too.
11. What's wrong with Grap.app?
12. An audio suite? I dunno. Logic seems to be alright.
Originally posted by Chucker
6. I don't believe in a Cocoa Finder, UNLESS it'll be a real new thing (which we need anyway), like the "Metadata Finder". The Metadata Finder, of course, would make iTunes and iPhoto more or less obsolete, as their main feature is file management. Playing MP3s, burning CDs and simple photo management doesn't require applications like iTunes or iPhoto.
When you have over 2,000 CDs and each individual CD is a playlist you start to see how amazing and wonderful iTunes is.
Originally posted by Jared
When you have over 2,000 CDs and each individual CD is a playlist you start to see how amazing and wonderful iTunes is.
He's saying that with a good metadata support in the Finder, iTunes won't be *as* necessary for music browsing. I'm sure iTunes will still remain the ideal browsing method, but you'll be able to achieve close to the same type browsing via the Finder if you wanted to.
Why? Apple is clearly moving everything to Cocoa.
Apple is constantly improving Cocoa...and Carbon is always a few steps behind. The Finder with a Cocoa interface would be in tune with what Apple has been doing in the past year: moving their software to Cocoa.
please provide a list of applications cocoa-ized by apple from carbon?
Apple is pushing developers to use Cocoa at this point. Carbon was great for OS 9 apps that needed porting to OS X...but Apple makes it clear that new projects or rewrites should be in Cocoa.
no matter how apple is pushing, developers are not willing to re invent the wheel to do the same thing again. yes, new application may be written in cocoa, but not the one has been done. why "may be"? it will depend on the user base. if one developer still has large os 8/9 customer base, i bet s/he will still use carbon, not cocoa to develope new app.
The Finder is in bad shape. Very bad shape. A rewrite in Cocoa would probably solve LOTS of problems as opposed to trying to heal a fatally wounded Carbon Finder...not because it's Cocoa, but because a rewrite would allow Apple to start fresh with things like a a new filesystem in mind as opposed to tacking it on as a hack to the existing Finder.
many people keep saying Finder in bad shape, well, it might be true in certain aspects, but this can not be translated into a cocoa Finder. from practical software developmental point of view, apple should not have two Finders, carbon and cocoa. it would be stupid to double QA testing work.
But let's face it folks...Cocoa allows for toolbars, drawers and quite a few neat-o things coming in 10.3 that won't be available to Carbon developers. Carbon and Cocoa may be unifying more and more but Apple says Cocoa should be used from now on, so why not bite the bullet and follow Apple's words of wisdom. They know best as to what Cocoa is and will become.
war here is not carbon vs cocoa, but os x vs os x-, which to improve os x. no doubts about it, this undertaking has been great drill already, now, before the platform gets a firm footage, people are asking for reshape the plan. it is not good.
i am still puzzled by the decision by apple on cocoa api. steve and avi have been in software business for quite long, did not they realize that rewrite a million lines of code of an existing application is a hugh undertaking? it just likes to dump english or any other earth language and instead, to adopt mars' language.
people also said that eventually every one will converge on cocoa. i seriously doubt it. i have 50k lines of code module and would like to rewrite it in a better way and clean way, my QA department fighted to stop it fiercly. so don't expect adobe, microsoft, or other bigger developers to rewrite their big applications. it is just unpractical.
Originally posted by Jared
When you have over 2,000 CDs and each individual CD is a playlist you start to see how amazing and wonderful iTunes is.
When you have over 200,000 e-mails from 2,000 different people you start to see how amazing and wonderful BeOS's tracker was.
What iTunes does is nothing but handling MP3 metadata through ID3 tags.
Originally posted by anakin1992 please provide a list of applications cocoa-ized by apple from carbon?
DVD Studio Pro 2, for example.
no matter how apple is pushing, developers are not willing to re invent the wheel to do the same thing again. yes, new application may be written in cocoa, but not the one has been done. why "may be"? it will depend on the user base. if one developer still has large os 8/9 customer base, i bet s/he will still use carbon, not cocoa to develope new app.
Agreed, mostly.
many people keep saying Finder in bad shape, well, it might be true in certain aspects, but this can not be translated into a cocoa Finder.
Agreed.
from practical software developmental point of view, apple should not have two Finders, carbon and cocoa. it would be stupid to double QA testing work.
I don't see how an application that's in development stage requires QA. A finished Cocoa Finder would of course replace the current one.
i am still puzzled by the decision by apple on cocoa api.
What decision?
Originally posted by Chucker
7. AppleWorks is dead, people.
FYI, AppleWorks got a minor update this month. It even comes in a new box which is similar to the new iLife apps and Keynote boxes. Check it out at AppleStore
Originally posted by Chucker
DVD Studio Pro 2, for example.
i know there are some applications being ported over to cocoa by apple, but the number is quite limited to very small range.
I don't see how an application that's in development stage requires QA. A finished Cocoa Finder would of course replace the current one.
yes, when a new feature is developed, QA is not involved. once design and unit testing are done, then QA is in. but designer is not off the hook.
to my understanding, current Finder is implemented in carbon and Finder is one of functionalities in OS X (let us just talke about jaguar alone for simplicity), while each of features in OS X has to be QA-ed indiviudally first and then integrated. now, you change, completely, on Finder and then you tell QA to redo the testing. i guess it is ok to ask them, but the problem is that you have to make sure the nice coordination on integration among various groups working on different features. if it is a standalone application, it might be easier. but dreadful thing happens if one thing changes everything else is affected. in addition, if there are couple of versions of the same features, dumping one for another is not easily being done.
i used to have just one branch of code base. but soon, various branches spawn because of new features coming in. for a smaller project, it is no brainer at all. for a big and collaborated project, it is nightmare to integrate various parts or modules. integration is only the first step, then comes to QA, then back to designer for bug fix then integration, then QA... it is an endless working cycles. so, i normally include QA into the design cycle and i understand that we could have various opinion and expereinces.
finally, a product is released, but that cycle is still there: bug report and fix and QA and on and on. suddently, a group wants to revamp what it has done, let us Finder, and have a completely new thing. basically, this causes us to the square 1.
Quote:
What decision?
the decision to use cocoa when they announced the new mac OS. years ago, (20 or 30 years ago?)linguists invented a univeral language which overcame every bad aspect of all the languages on this planet and hoped it to adopted worldwide. looking around ourselves now, who is using it? english is dominant now, at least in computing and scientific areas, though in pure linguistic point of view english is no better than indian native language at all.
i guess what i tried to point out was that no matter what technology there is, if it can not, practically, solve the problems for your customer and facilitate their work, then it is useless. in apple's case, the customers are adobe, microsoft, and others.
Originally posted by pallando2372
FYI, AppleWorks got a minor update this month. It even comes in a new box which is similar to the new iLife apps and Keynote boxes. Check it out at AppleStore
I know. That doesn't make it any less dead.
Originally posted by anakin1992
to my understanding, current Finder is implemented in carbon and Finder is one of functionalities in OS X (let us just talke about jaguar alone for simplicity), while each of features in OS X has to be QA-ed indiviudally first and then integrated. now, you change, completely, on Finder and then you tell QA to redo the testing. i guess it is ok to ask them, but the problem is that you have to make sure the nice coordination on integration among various groups working on different features. if it is a standalone application, it might be easier. but dreadful thing happens if one thing changes everything else is affected.
For me, the Finder is just (or should be) a GUI for file management. Have you tried Path Finder? It does almost all the Finder does, and more (Converting Pictures, Mounting Disk Images, ...). It's written in Cocoa, looks almost like the Finder, and obviously didn't require any kind of source code from the "real" Finder. The Finder shouldn't be all that complex, and thus, QA testing shouldn't be, either.
the decision to use cocoa when they announced the new mac OS.
You mean the decision to buy NeXT and use their operating system base? It was a damn right decision.
years ago, (20 or 30 years ago?)linguists invented a univeral language which overcame every bad aspects of all the languages on this planet and hoped it to adopted worldwide. looking around ourselves now, who is using it? english is dominant now, at least in computing and scientific areas, though in pure linguistic point of view english is no better than indian native language at all.
If you mean Esperanto, that was 150 years ago. It didn't work out because English just worked already
Originally posted by anakin1992
i know there are some applications being ported over to cocoa by apple, but the number is quite limited to very small range.
No, it's definitely a direction at Apple. And not so small.
just a few Carbon to Cocoa rewrites
iMovie 2 --> iMovie 3
DVD Studio Pro --> DVD Studio Pro 2
Java 1.3 --> Java 1.4
iDVD --> iDVD 2
Apple System Profiler (10.1) --> Apple System Profiler (10.2)
Help Viewer (10.1) --> Help Viewer (10.2)
AppleScript Editor (10.1) --> Script Editor Beta
And so on.
If anything, the trend seems to be increasing. And of course, practically all new Apple apps are Cocoa.
The Carbon vs. Cocoa debate, when shifted away from its most tiresome, black and white form ("Carbon apps suck! Make it in Cocoa!" "Cocoa apps are slow and suck!") is kind of interesting. Apple has insisted Carbon and Cocoa will be equal citizens, but at the same time it's clear they are moving as much app development over to Cocoa as possible. I actually wouldn't be surprised to hear if there are considerable Cocoa chunks in the Panther Finder.
Question is, can Apple afford to support parallel development in two APIs as new features are added? In the short-term future, sure. It's the long-term future that's more of a mystery.
I'll be interested whether WWDC clears up some of the haze over the future of Carbon vs. Cocoa development.
edit. crx typos.
Originally posted by Chucker
For me, the Finder is just (or should be) a GUI for file management. [snipped...]
yes, but behind the door, the mechanism to provide a way to relay apple events between the Finder and an Application is done differently, though i hope not, between cocoa and carbon: cocoa is done in an ood way and i don't think carbon uses the same way.
the path Finder is the same as the Finder? i doubt it, but since i never used it before, i can not say much. there is a way to quite the Finder in jaguar. then can you start the Path Finder? is this the Path Finder has to work with the Finder first? anyone knows about it? please post your opinions and thanks ahead.
Originally posted by Hobbes
No, it's definitely a direction at Apple. And not so small.
just a few Carbon to Cocoa rewrites
iMovie 2 --> iMovie 3
DVD Studio Pro --> DVD Studio Pro 3
Java 1.3 --> Java 1.4
iDVD --> iDVD 2
Apple System Profiler (10.1) --> Help Viewer (10.2)
Help Viewer (10.1) --> Help Viewer (10.2)
AppleScript Editor (10.1) --> Script Editor Beta
And so on.
many thanks for the info. i only knew couple of them. one example makes me quite wonder: if i have an old java application on java 1.3, now in order to use java 1.4, do i have to rework my application to fit java 1.4? normally, i would continue to use java 1.3. but the problem occurs when apple will only update on java 1.4 on bug fix or new features, then i have to be forced to do things in java 1.4. it is ok for once to do it. what about sometime later apple finds a new way to do java on mac os x, what am i going to do again?
If anything, the trend seems to be increasing. And of course, practically all new Apple apps are Cocoa.
yeah, it makes much sense to have complete new application in cocoa. by new, i meant, no reuse on the old code. not just for apple, every one else should use cocoa for new app. but the question remains: are those old apps, such as word, excell, ps, etc to be written in cocoa or not? another interesting question will be: are there any new apps that are going to replace those old apps in carbon, such as word, etc?
The Carbon vs. Cocoa debate, when shifted away from its most tiresome, black and white form ("Carbon apps suck! Make it in Cocoa!" "Cocoa apps are slow and suck!") is kind of interesting. Apple has insisted Carbon and Cocoa will be equal citizens, but at the same time it's clear they are moving as much app development over to Cocoa as possible. I actually wouldn't be surprised to hear if there are considerable Cocoa chunks in the Panther Finder.
i am not against using cocoa or carbon, as long as it works, i am fine. but what do customers think? if new Finder in panther is cooked in cocoa, what are the effects this change will bring to the behaviors on the interaction between the Finder and application?
Question is, can Apple afford to support parallel development in two APIs as new features are added? In the short-term future, sure. It's the long-term future that's more of a mystery.
the only ways i think of that apple will be ok are that there will be a new technology, either hardware or software, rendering both carbon and cocoa as usless or at least not efficient any more; or, apple decides to dump all the old buddies, like adobe, microsoft, etc and dose every thing by itself.
Originally posted by anakin1992
many thanks for the info. i only knew couple of them. one example makes me quite wonder: if i have an old java application on java 1.3, now in order to use java 1.4, do i have to rework my application to fit java 1.4? normally, i would continue to use java 1.3. but the problem occurs when apple will only update on java 1.4 on bug fix or new features, then i have to be forced to do things in java 1.4. it is ok for once to do it. what about sometime later apple finds a new way to do java on mac os x, what am i going to do again?
What incompatibilities there are have everything to do with the changes from Java 1.3 to Java 1.4.1 and Apple's as-yet-incomplete implementation of 1.4.1. The move from Carbon to Cocoa underneath should have absolutely no effect on compatibility. What it does is reduce the number of man-hours required for design, coding and testing, and the number of lines of code that can introduce bugs. That's why Apple's moving so much development to Cocoa: They can get more done in less time with fewer programmers, and with fewer lines of code.
yeah, it makes much sense to have complete new application in cocoa. by new, i meant, no reuse on the old code. not just for apple, every one else should use cocoa for new app. but the question remains: are those old apps, such as word, excell, ps, etc to be written in cocoa or not? another interesting question will be: are there any new apps that are going to replace those old apps in carbon, such as word, etc?
One persistent fallacy in this thread is that an application has to be Carbon or Cocoa. Nothing at all prevents a vendor with a big C++ app linked to Carbon from redoing the GUI in IB and the view layer(s) in Cocoa, and linking against a Carbon back end. The issues are: How well-factored is the code, how quickly can the developers get up to speed (Apple argues, from their own experience, that this curve is relatively low), and how many advantages can be gained from linking to a framework like Cocoa and (optionally) from a lean, dynamic language like Objective-C.
In fact, any Cocoa app that deals with QuickTime is going to have a healthy amount of Carbon code in it.
i am not against using cocoa or carbon, as long as it works, i am fine. but what do customers think? if new Finder in panther is cooked in cocoa, what are the effects this change will bring to the behaviors on the interaction between the Finder and application?
Ideally, the customers shouldn't notice. The decision to use an API should be a development decision. In practice, Cocoa allows a few developers to write a very slick application with comparatively few lines of code, so Cocoa apps are often considered more polished just because apps get all that behavior for next to nothing. This is not intrinsic, of course, because Mac OS Toolbox apps achieved high levels of polish despite being on an API more primitive than Carbon — it just required a lot of elbow grease to get there.
Along these lines, A Cocoa Finder will make little to no difference to any other applications (whose interactions with the Finder are pretty minimal as it is). They pop the same windows, get the same events, and so forth. They handle these things differently internally, but what they do internally is irrelevant. Currently, Finder forwards most events to an application called System Events. If that doesn't change, nobody will notice whether Apple recodes the Finder in Objective-C/Cocoa, or in pure Java.
(This assumes that Apple doesn't intend to completely reinvent the Finder, rather than simply moving the existing Finder to Cocoa. In that case, the reinvention would be what sparked the change, since it would be different even if Apple had kept it a Carbon app.)
the only ways i think of that apple will be ok are that there will be a new technology, either hardware or software, rendering both carbon and cocoa as usless or at least not efficient any more; or, apple decides to dump all the old buddies, like adobe, microsoft, etc and dose every thing by itself.
Why?! Carbon suffices for some cross-platform and old-school Macintosh developers, and for apps like Ambrosia's Snapz Pro that are better served with a low-level API. Cocoa brings over all the old NeXT applications easily and provides a very attractive way to develop Mac applications, especially for small developers. Java brings in a whole other audience as well. None of these APIs are going to go anywhere, and none of them are being neglected. In fact, Apple has been hard at work unifying them over CoreFoundation. Cocoa and Carbon and C and C++ and Objective-C can be commingled freely, and Python and Java and AppleScript can talk to them and be linked to them. This integration is getting tighter and more complete with every release. There's no need for anything new; if something new comes along (Microsoft's .NET?) it can be built on top of the same Foundation that the rest are, and join the party.
The real issue here is that the final appearance, reliability, performance and polish of an application is up to the developers, not the API (although the language and API chosen will help or hinder these goals variously — it's the developer's job to pick the most appropriate ones). Whether it's a Cocoa app, or Carbon, or Java, or RealBasic, or AppleScript Studio, or what-have-you should be completely transparent to the end user. In the end, a Mac application is a Mac application; if it isn't, the developers didn't do their jobs.