Fully agreed. Carbon is the better environment for doing serious work, since ultimately it has less overhead and allows the programmer more freedom. I find that Cocoa's strength is in providing a fast way to develop small to medium sized apps for OS X. For that, it's really great. However, The Finder is definitely a serious app, and there's no reason for it to be written in one paradigm over another as long as the result is the same. Programs just end up as ones and zeros anyway: for the end user, the strata of the equivalent subroutines they call is moot. . . And we're all end users unless we happen to be Apple employees working on Finder.
Fully agreed. Carbon is the better environment for doing serious work, since ultimately it has less overhead and allows the programmer more freedom. I find that Cocoa's strength is in providing a fast way to develop small to medium sized apps for OS X. For that, it's really great. However, The Finder is definitely a serious app, and there's no reason for it to be written in one paradigm over another as long as the result is the same. Programs just end up as ones and zeros anyway: for the end user, the strata of the equivalent subroutines they call is moot. . . And we're all end users unless we happen to be Apple employees working on Finder.
Get used to Cocoa or plan on switching platforms. And for Finder, the Cocoa Finder was there before the merger.
Carbon is not the better environment. Then again, if I'm wasting my breath on someone who is a legacy Mac developer I'll stop right now.
I'm not a programmer, and couldn't even play one on TV, but this isn't really that hard to resolve.
The Finder is Carbon, for two reasons. Back in the early OS X days, Cocoa wasn't as feature rich as Carbon (as still isn't apparently.) But the bigger reason was that many developers needed a solid bridge to OS X, and Apple's building an app as important as the Finder in Carbon helped that process immensely.
Fast forward five years. Carbon was a good and solid bridge, but the future of OS X resides in Cocoa and Xcode. Thus Apple, which must be preparing a Finder replacement by now (or Brad's head will explode) will be using Cocoa for the project.
The end result will be to find bugs and make Cocoa more feature complete.
Avie stepped aside from the day-to-day management of Mac OS X development back in 2003. It's been Bertrand Serlet's gig since that time. They're both ex-NeXTies with similar philosophies, so the difference isn't really that noticable.
IOW, the impact of Avie's departure from Apple will be negligible.
It will affect the developer greatly in years to come. They will get easy access to fewer and fewer of OS X's new whiz-bang features.
So, in other words, it doesn't affect me at all -- as a user.
As far as development is concerned, my personal needs are focused on portability between the Mac and other POSIX environments (namely Linux). So ultimately my best option is write back-ends in POSIX C and front-ends for Java, X11, and/or Open GL. To say that it's foolish to do so, or that I "should get used to Cocoa or switch platforms" is the biggest piece of self-righteous crap I've heard in a long time. Apple has gone out of its way to ensure that progams can get to the mac from many different beginnings. It's naive to think that this is suddenly going to stop because Tevanian is leaving.
Why? How does it really affect me if a program is written in Cocoa or Carbon if they both do the same thing (memory footprint aside)?
Sure, it affects you if you are a user:
If it's a carbon app, you don't have access to the font menu (and other standard cocoa menus for that matter), to the service menu (though it's better right now), and so on...
So you loose a lot in integration.
That said using cocoa doesn't make you write necessarily great applications. There are some carbon apps without concurence: GraphicConverter, Vuescan and a few other ones.
But I try to use cocoa for everything else since I found that (when I was making no difference) my permissions were broken constantly by rude carbon apps. Now that I use almost exclusively cocoa apps, I never have to rebuild the permissions!
(I installed cocoa Gestures for the unique purpose to verify if a app is cocoa!)
Cocoa apps have another problem where the text views don't behave like Mac text views. For some reason, Apple refuses to acknowledge, let alone solve, this problem. I suspect the reason is that Cocoa is maintained by former NeXT-heads.
The problem is easy to spot. If you select from the bottom-up in any paragraph, choosing whether to select the trailing linefeed of the previous paragraph is as simple as moving the cursor to the left or right margin while dragging. This is true for both Carbon and Cocoa apps. However, when selecting from the top-down the behavior is only consistent in Carbon apps; Cocoa apps will always select the trailing linefeed unless you aim the cursor at a small area after the linefeed. I find this so damned annoying I can't use any Cocoa app for editing text, including Project Builder.
The delay when dragging text is idiotic too. Either have D&D text or not; the delay makes no sense. A delay gesture makes more sense for a contextual menu, but that can't be used if the delay does something else.
Apple could solve this problem at any time and no 3rd party apps would have to change. The problem of using file paths (NSStrings) as file metaphors, on the other hand, would require an API change.
Maybe this has to do with rosetta and expanded uses, like intercepting Windows calls and mapping them to MacOS calls for a way to run Windows programs and make them look like Mac programs.
Maybe I can organize my applications folder the way I want to now. Avie wanted apps to be hard coded to a path, rather than referred to by a code number. This is why if I create an iLife folder in my Apps directory, software update won't see them. Incredibly frustrating as this was not the case in OS 9.
Maybe I can organize my applications folder the way I want to now. Avie wanted apps to be hard coded to a path, rather than referred to by a code number. This is why if I create an iLife folder in my Apps directory, software update won't see them. Incredibly frustrating as this was not the case in OS 9.
That NeXT-ism has a lot to do with its UNIX heritage. Same with, ugh, filename extensions.
Note that I don't believe all the Mac-isms in OS X are good. For example, I'm glad Tinker Tool allows me to disable the desktop. The desktop (as a clickable object) was one of the WORST HI decisions ever! I say this as a daily Mac user since 1986. For some reason, Microsoft incorporated it into Windows where it's even worse. Exposé almost makes it bearable, but I prefer disabling it anyway.
I'm just anti-stupid. The behavior of Mac text views was one of the things Apple got right and everyone else got horribly wrong. Cocoa text views aren't as bad as windoze, but they're clearly inferior to Carbon ones (viz. WASTE) in terms of selection and drag behavior.
Yeah blue2kdave...that um...has to go. Very Windowstacular.
Actually Windows installers nearly always let you choose where to install apps.
This is a NeXT/UNIX-ism.
What Apple ought to do is reform the API and interface like they did with System 7. That was pretty much the last time Apple seemed to put any effort into improving the overall HI (well, except for some clarification on layout which they added with "Aqua")
That NeXT-ism has a lot to do with its UNIX heritage. Same with, ugh, filename extensions.
I'm just anti-stupid. The behavior of Mac text views was one of the things Apple got right and everyone else got horribly wrong. Cocoa text views aren't as bad as windoze, but they're clearly inferior to Carbon ones (viz. WASTE) in terms of selection and drag behavior.
I'm not sure about that. I always thought -- back in '89 -- that the NeXT behavior was a progress (double clic, triple clic, erase the space with the word, etc?)
And I think that since Bud Tribble is behind that (he was behind the Macintosh project too by "coïncidence") you have NO CHANCE that it will change and it's a good thing. Carbon is dead!
No, they're not. They're a far inferior idea compared to file system-level file type Metadata, based on type/creator, MIME types or UTIs. There is not a single reason users should have to deal with such a kludge of stupid characters appended to file names in 2006, aside from the dreaded problem of compatibility.
I'm not sure about that. I always thought -- back in '89 -- that the NeXT behavior was a progress (double clic, triple clic, erase the space with the word, etc?)
And I think that since Bud Tribble is behind that (he was behind the Macintosh project too by "coïncidence") you have NO CHANCE that it will change and it's a good thing. Carbon is dead!
You obviously read my post through anti-Carbon tinted glasses.
My problem with Cocoa's implementation isn't with triple-click or else I would have said so. The problem is with drag selecting text. The Carbon method allows you to choose whether to select the trailing linefeed by a simple left or right gesture when selecting up or down, while the Cocoa method only allows this when selecting up.
Comments
Originally posted by Chucker
[B]Please name a reason to make it Cocoa.
. . .
Fully agreed. Carbon is the better environment for doing serious work, since ultimately it has less overhead and allows the programmer more freedom. I find that Cocoa's strength is in providing a fast way to develop small to medium sized apps for OS X. For that, it's really great. However, The Finder is definitely a serious app, and there's no reason for it to be written in one paradigm over another as long as the result is the same. Programs just end up as ones and zeros anyway: for the end user, the strata of the equivalent subroutines they call is moot. . . And we're all end users unless we happen to be Apple employees working on Finder.
Originally posted by Splinemodel
Fully agreed. Carbon is the better environment for doing serious work, since ultimately it has less overhead and allows the programmer more freedom. I find that Cocoa's strength is in providing a fast way to develop small to medium sized apps for OS X. For that, it's really great. However, The Finder is definitely a serious app, and there's no reason for it to be written in one paradigm over another as long as the result is the same. Programs just end up as ones and zeros anyway: for the end user, the strata of the equivalent subroutines they call is moot. . . And we're all end users unless we happen to be Apple employees working on Finder.
Get used to Cocoa or plan on switching platforms. And for Finder, the Cocoa Finder was there before the merger.
Carbon is not the better environment. Then again, if I'm wasting my breath on someone who is a legacy Mac developer I'll stop right now.
I'm not a programmer, and couldn't even play one on TV, but this isn't really that hard to resolve.
The Finder is Carbon, for two reasons. Back in the early OS X days, Cocoa wasn't as feature rich as Carbon (as still isn't apparently.) But the bigger reason was that many developers needed a solid bridge to OS X, and Apple's building an app as important as the Finder in Carbon helped that process immensely.
Fast forward five years. Carbon was a good and solid bridge, but the future of OS X resides in Cocoa and Xcode. Thus Apple, which must be preparing a Finder replacement by now (or Brad's head will explode) will be using Cocoa for the project.
The end result will be to find bugs and make Cocoa more feature complete.
Originally posted by tink
Maybe .........
lol...
if this is really true that Avie is leaving then Apple is really DOOOOOM!!
Cause as far as i know Avie is one of the key employee of Apple.
IOW, the impact of Avie's departure from Apple will be negligible.
Originally posted by mdriftmeyer
Get used to Cocoa or plan on switching platforms.
Why? How does it really affect me if a program is written in Cocoa or Carbon if they both do the same thing (memory footprint aside)?
Originally posted by Splinemodel
Why? How does it really affect me if a program is written in Cocoa or Carbon if they both do the same thing (memory footprint aside)?
It will affect the developer greatly in years to come. They will get easy access to fewer and fewer of OS X's new whiz-bang features.
Again, Carbon's great for modern apps and is more feature rich at the moment.
But extending the Cocoa/Xcode combo is Apple's priority right now. Anyone can see that.
Originally posted by Frank777
It will affect the developer greatly in years to come. They will get easy access to fewer and fewer of OS X's new whiz-bang features.
So, in other words, it doesn't affect me at all -- as a user.
As far as development is concerned, my personal needs are focused on portability between the Mac and other POSIX environments (namely Linux). So ultimately my best option is write back-ends in POSIX C and front-ends for Java, X11, and/or Open GL. To say that it's foolish to do so, or that I "should get used to Cocoa or switch platforms" is the biggest piece of self-righteous crap I've heard in a long time. Apple has gone out of its way to ensure that progams can get to the mac from many different beginnings. It's naive to think that this is suddenly going to stop because Tevanian is leaving.
Originally posted by Splinemodel
Why? How does it really affect me if a program is written in Cocoa or Carbon if they both do the same thing (memory footprint aside)?
Sure, it affects you if you are a user:
If it's a carbon app, you don't have access to the font menu (and other standard cocoa menus for that matter), to the service menu (though it's better right now), and so on...
So you loose a lot in integration.
That said using cocoa doesn't make you write necessarily great applications. There are some carbon apps without concurence: GraphicConverter, Vuescan and a few other ones.
But I try to use cocoa for everything else since I found that (when I was making no difference) my permissions were broken constantly by rude carbon apps. Now that I use almost exclusively cocoa apps, I never have to rebuild the permissions!
(I installed cocoa Gestures for the unique purpose to verify if a app is cocoa!)
The problem is easy to spot. If you select from the bottom-up in any paragraph, choosing whether to select the trailing linefeed of the previous paragraph is as simple as moving the cursor to the left or right margin while dragging. This is true for both Carbon and Cocoa apps. However, when selecting from the top-down the behavior is only consistent in Carbon apps; Cocoa apps will always select the trailing linefeed unless you aim the cursor at a small area after the linefeed. I find this so damned annoying I can't use any Cocoa app for editing text, including Project Builder.
The delay when dragging text is idiotic too. Either have D&D text or not; the delay makes no sense. A delay gesture makes more sense for a contextual menu, but that can't be used if the delay does something else.
Apple could solve this problem at any time and no 3rd party apps would have to change. The problem of using file paths (NSStrings) as file metaphors, on the other hand, would require an API change.
Originally posted by blue2kdave
Maybe I can organize my applications folder the way I want to now. Avie wanted apps to be hard coded to a path, rather than referred to by a code number. This is why if I create an iLife folder in my Apps directory, software update won't see them. Incredibly frustrating as this was not the case in OS 9.
That NeXT-ism has a lot to do with its UNIX heritage. Same with, ugh, filename extensions.
Note that I don't believe all the Mac-isms in OS X are good. For example, I'm glad Tinker Tool allows me to disable the desktop. The desktop (as a clickable object) was one of the WORST HI decisions ever! I say this as a daily Mac user since 1986. For some reason, Microsoft incorporated it into Windows where it's even worse. Exposé almost makes it bearable, but I prefer disabling it anyway.
I'm just anti-stupid. The behavior of Mac text views was one of the things Apple got right and everyone else got horribly wrong. Cocoa text views aren't as bad as windoze, but they're clearly inferior to Carbon ones (viz. WASTE) in terms of selection and drag behavior.
Originally posted by Aquatic
Yeah blue2kdave...that um...has to go. Very Windowstacular.
Actually Windows installers nearly always let you choose where to install apps.
This is a NeXT/UNIX-ism.
What Apple ought to do is reform the API and interface like they did with System 7. That was pretty much the last time Apple seemed to put any effort into improving the overall HI (well, except for some clarification on layout which they added with "Aqua")
Now we know why Avie left the company.
Originally posted by Brendon
Boot Camp
Now we know why Avie left the company.
Originally posted by strobe
That NeXT-ism has a lot to do with its UNIX heritage. Same with, ugh, filename extensions.
I'm just anti-stupid. The behavior of Mac text views was one of the things Apple got right and everyone else got horribly wrong. Cocoa text views aren't as bad as windoze, but they're clearly inferior to Carbon ones (viz. WASTE) in terms of selection and drag behavior.
I'm not sure about that. I always thought -- back in '89 -- that the NeXT behavior was a progress (double clic, triple clic, erase the space with the word, etc?)
And I think that since Bud Tribble is behind that (he was behind the Macintosh project too by "coïncidence") you have NO CHANCE that it will change and it's a good thing. Carbon is dead!
And file extensions are a GOOD thing!
Originally posted by frogggy
And file extensions are a GOOD thing!
No, they're not. They're a far inferior idea compared to file system-level file type Metadata, based on type/creator, MIME types or UTIs. There is not a single reason users should have to deal with such a kludge of stupid characters appended to file names in 2006, aside from the dreaded problem of compatibility.
Originally posted by frogggy
I'm not sure about that. I always thought -- back in '89 -- that the NeXT behavior was a progress (double clic, triple clic, erase the space with the word, etc?)
And I think that since Bud Tribble is behind that (he was behind the Macintosh project too by "coïncidence") you have NO CHANCE that it will change and it's a good thing. Carbon is dead!
You obviously read my post through anti-Carbon tinted glasses.
My problem with Cocoa's implementation isn't with triple-click or else I would have said so. The problem is with drag selecting text. The Carbon method allows you to choose whether to select the trailing linefeed by a simple left or right gesture when selecting up or down, while the Cocoa method only allows this when selecting up.