None of you seem to really get it. There already exists a Cocoa Finder. How it evolves into OS X 10.5 is up to the design team.
There was a Cocoa Finder back in 1997. The Finder was redeveloped to address the Classic/Carbon issues and thus the Cocoa Finder (Workspace Manager and future children) were put on hold.
When Steve stated that OS X for Intel has been built since 2000 he isn't telling the entire story. It was built since 1997/98 as Rhapsody for Intel.
He synced up the dates when OS X was first hobbled out.
People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.
COCOA is the Future of OS X.
Don't believe me. Go get a job at Apple Engineering.
People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.
COCOA is the Future of OS X.
Don't believe me. Go get a job at Apple Engineering.
I don't think you really understand what's been said already.
The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.
If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.
The Finder's problems stem from three problems:
A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point.
All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.
The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.
It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.
Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.
If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.
I don't think you really understand what's been said already.
The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.
If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.
The Finder's problems stem from three problems:A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point. All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it. Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.
The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.
It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.
Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.
If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.
[*]All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
This isn't a showstopper, it just means the application needs to take care of moving the data from the worker threads to the GUI thread.
That's not the point. The point is Cocoa doesn't help.
You don't want a 100% Cocoa Finder anyway. It wouldn't even be able to handle Aliases.
What exactly would you want to use Cocoa APIs? The views? What would THAT solve?!
Well if you'd read the discussion above you'd see that the use of Cocoa in-and-of itself wouldn't solve anything. To have a Cocoa Finder would imply a complete re-write, however, and perhaps then we'd have one that would solve the often made complaints.
Comments
There was a Cocoa Finder back in 1997. The Finder was redeveloped to address the Classic/Carbon issues and thus the Cocoa Finder (Workspace Manager and future children) were put on hold.
When Steve stated that OS X for Intel has been built since 2000 he isn't telling the entire story. It was built since 1997/98 as Rhapsody for Intel.
He synced up the dates when OS X was first hobbled out.
People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.
COCOA is the Future of OS X.
Don't believe me. Go get a job at Apple Engineering.
Originally posted by mdriftmeyer
People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.
COCOA is the Future of OS X.
Don't believe me. Go get a job at Apple Engineering.
I don't think you really understand what's been said already.
The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.
If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.
The Finder's problems stem from three problems:
- A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point.
- All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
- Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.
The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.
Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.
If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.
Originally posted by rmcgann220
I don't think you really understand what's been said already.
The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.
If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.
The Finder's problems stem from three problems:A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point.
All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.
The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.
It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.
Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.
If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.
Come back when you've learnt how to read.
Originally posted by rmcgann220
[*]All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
This isn't a showstopper, it just means the application needs to take care of moving the data from the worker threads to the GUI thread.
Originally posted by Programmer
This isn't a showstopper, it just means the application needs to take care of moving the data from the worker threads to the GUI thread.
That's not the point. The point is Cocoa doesn't help.
You don't want a 100% Cocoa Finder anyway. It wouldn't even be able to handle Aliases.
What exactly would you want to use Cocoa APIs? The views? What would THAT solve?!
Originally posted by strobe
That's not the point. The point is Cocoa doesn't help.
You don't want a 100% Cocoa Finder anyway. It wouldn't even be able to handle Aliases.
What exactly would you want to use Cocoa APIs? The views? What would THAT solve?!
Well if you'd read the discussion above you'd see that the use of Cocoa in-and-of itself wouldn't solve anything. To have a Cocoa Finder would imply a complete re-write, however, and perhaps then we'd have one that would solve the often made complaints.