Most of the programs that do this don't really seem to have a reason to keep running. If you still want to use the program later in a session, it seems to be much quicker to hide and unhide apps than it is to close a window and re open it.
Some apps, such as iTunes, have lower CPU usage with no windows open (whether those apps are hidden or not). Also, it is totally inconsistent. Why should the user have to remember which apps quit when you close the last window, and which don't? For example, Address book stays open when you close its window, but calculator does not. In order to fix the consistency problem, I'd much rather that things change to all apps staying open until you choose "quit" than all apps quitting when you close their final window.
As a single-window app, Address Book used to quit on close. Apple changed this upon adding Bluetooth support, where an incoming call can display caller ID on the Mac's screen. To maintain the Bluetooth connection, Address Book must remain running, hence the change.
Excellent use cases can be provided for both types of behavior, and IMHO this 'inconsistency' does little if any harm to users. The simple cases - iPhoto, PhotoBooth - *are* simple, while more complex cases - mulitple window/document apps, Adress Book - aren't, and necessarily so. Shoehorning everything into a single model would eliminate the simple cases and possibly introduce greater complexity in the long run via complex corner cases. For strawman examples to the contrary, witness the disaster that is MS Word's "what will this 'X' button do?" MDI-bastard-child interface on Windows.
So I think Apple is being open-minded and possibly even forward-looking. Eventually, I suspect we'll see the notion of 'Quit' or process termination removed from interface vocabulary altogether. Applications will always maintain a user's working state and won't ever terminate or quit - they'll simply suspend to virtual memory. The processes will automatically come and go as the app and OS deem necessary.
If you have enough RAM, OS X functions much this way already; just leave everything running. At this point the only compelling (inteface) rationale for 'Quitting' is to free up the dock and return its icons to a reasonable size - solely an interface contrivance, to be sure.
I said this before and got no responses, but wouldn't it be easy to make applications that quit upon closing a window have a square red button instead of a round one? Instant feedback on what will happen.
I said this before and got no responses, but wouldn't it be easy to make applications that quit upon closing a window have a square red button instead of a round one? Instant feedback on what will happen.
If you are going to keep some apps quitting upon closure of final window, and some not, this is the obvious solution. I have no idea why Apple doesn't do it or something similar.
Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?
Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?
Don't even need to know?? I think it's important that users know whether an app is going to quit or not when they perform a particular action.
10. Shift-arrow selection behaviour. Like someone else said, this is not limited to the Finder, but is worth mentioning because it is IMHO the single most annoying thing in OS X. It really pisses me off. Really.
\tUsing iTunes as an example: In an iTunes playlist, multiple tracks can be selected by clicking on a track, then holding down the shift key whilst pressing the up/down arrow keys.
\tPressing the down arrow key always extends the selection downwards, whilst pressing the up arrow key always extends the selection upwards. This means that it is impossible to contract your selection, you can only make it bigger.
\tI find this highly annoying and think that the selection process should work like selection of text in other applications such as TextEdit. This would make the interface more consistent and more intuitive. The function of the up/down arrow keys should depend on the direction in which the selection was originally extended.
\tFor example, imagine wanting to make a selection starting at a particular song and extending downwards: if you overshoot your intended selection, you should be able to contract the selection by pressing the up arrow key. Correspondingly, if your original selection was upwards, pressing the down arrow key should then contract the selection.
You use the cmd (Apple) key for that. I always combine two keys for selections, cmd for single or selective selections, shift for filing the gaps if neccessary. It works, but most people don't know you can use cmd for it. And I'm not sure if the use of the cmd-key is a consistent or logical UI feature for this.
You use the cmd (Apple) key for that. I always combine two keys for selections, cmd for single or selective selections, shift for filing the gaps if neccessary. It works, but most people don't know you can use cmd for it. And I'm not sure if the use of the cmd-key is a consistent or logical UI feature for this.
No, you can't. You have misunderstood.
Do this: Open a folder that contains several items in the Finder, and set it to list view. Now, select one of the items in the middle. Now hold down the shift key, and press the down arrow. Keeping the shift key held down, every time you press the down arrow, the selection will extend downwards. There is no way to contract the selection. If you press the up arrow, the selection will extend upwards.
Do the same in text edit when selecting text and you will notice different, and much more intuitive behaviour.
Don't even need to know?? I think it's important that users know whether an app is going to quit or not when they perform a particular action.
Yes, I would argue (and do so, above) that we will soon reach a point where users will neither have to know nor care whether an application is 'running' or not. But, granted, that time has not yet arrived.
"Is it important that users know whether or not an app will quit when they perform a particular action?" (specifically, clicking the red 'X' button)
No, it is not. As long as that action does not result in loss of user data or other relevant state, it is not important. *Certainly* not important enough to introduce an interface curiosity whereby some 'X' buttons are shaped differently than others... talk about inconsistency!
Now, let's try a slightly different question: is it important that users know whether or not an app has quit in response to a particular action? For the sake of this argument, sure. Look at the menu bar; is the app's name there? Check the dock; can you find its icon?
My point: there is no need to know 'in advance' exactly what the close button will do, so long as it doesn't do anything 'bad' *and*, if you're an individual who happens to care, there are means for determining the result after the fact. If you care, and an app's close button behaves consistently, you will quickly learn its behavior.
My point: there is no need to know 'in advance' exactly what the close button will do, so long as it doesn't do anything 'bad' *and*, if you're an individual who happens to care, there are means for determining the result after the fact. If you care, and an app's close button behaves consistently, you will quickly learn its behavior.
Are you trying to tell me it's not a pain when an Application quits when you are not expecting it to?
I agree that making the round widget square would probably be going too far, and that's why I said "or something similar" would be a good idea. If the app is going to quit, the "x" that appears inside the circle could be itself enclosed in a square. This would give the user some advance warning that pressing the widget will result in the application quitting.
There are some applications which people do not use very often, and it is therefore easy to forget whether it is an app that quits upon closure of final window or not. Also, the application may have been updated (as part of an OS update for example) since the last time you used it, and its behaviour in this regard may have changed. Some visual indicator of what is about to happen would be nice.
It is important to note that I don't think this a major problem, mac os is not doomed because of this flaw. It is just one of those "little things" that would be nice if it were fixed.
..."Is it important that users know whether or not an app will quit when they perform a particular action?" (specifically, clicking the red 'X' button)
No, it is not. As long as that action does not result in loss of user data or other relevant state, it is not important. *Certainly* not important enough to introduce an interface curiosity whereby some 'X' buttons are shaped differently than others... talk about inconsistency!
...
Actually, i like what you are proposing.
Generally, I do understand theoretically why there is some
different behavior regarding on clicking the red X button.
(1) Apps, which create and manage docs (content) do not quit by clicking
the red X. A no brainer.
(2) Apps, which are single window apps like System Prefpane, Calculator
and some other quit on clicking.
But i do not agree the philosophy behind that. I think it is a flaw
in UI design, yes, ... talk about inconsistency!
I am always asking myself, why the very same action (clicking the red X)
produces different results (either quit or close). No big deal, but
the inconsistency does exist. MS Windows produces more consistency
in this regard.
I belong to that specie that never ever quit any app, i almost always
use CMD-H. I just want to have my apps steadily on standby. I feel
more comfortable that way.
As a sidenote: in the Mac OS 8/9 days, hiding an app gave us
a huge speed advantage over MS Windows, remember.
Opening a large PS doc was almost instantly, just because the
I don't like the Finder very much either. One thing that I keep thinking though is why would it be so hard to make a new one? We have a very efficient and stable unix base that can do pretty much everything the Finder does. Why not just turn the Finder into a scripted front end for unix tools. Finder style file moves and renames can call the unix mv function. Finder copies can call the dd function and could even do IO error handling where the Finder currently fails. Isn't disk utility just a front end to the diskutil/hdiutil commands?
I think that with that approach, you could very quickly design a fully functional, stable, lightweight, multi-threaded finder. It would also tie in much better with terminal commands as it would just be using the same commands itself. If it was mostly done in some sort of scripting way, it could be more easily customized by end users too and that would also speed up development.
I also wouldn't mind seeing some sort of revolutionary file viewing feature. The column view is my favourite of all of the 3 we have but it still has that sliding problem when moving files. Since Spotlight indexes a lot of the filesystem, I wonder if it would be possible to have a big window that displayed every folder in the entire filesystem at once as some sort of tree view. This view would encourage users to have a more ordered filesystem. Often times I see people store lots of files on the desktop and then put one or two files 20 hierarchies deep. That makes finding the files you want inefficient.
Obviously with so many folders in an OS X system, the window would need to have a zoom function (preferrably with the mouse wheel and +/- buttons for users of crappy mice ). When a folder was selected, it could show a list view of the files in it maybe on the right of the window. It's then pretty easy to move these files to any folder in the entire filesystem. The list view could be tabbed too and changed to icon view.
Lastly, I think it would be good to have the Finder always accessible without switching the current application to the background. Maybe if there was a menu item like spotlight that dropped down the file browser. One use I could see is for dragging images out of Safari. You can drop images straight into your filesystem.
Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?
It wouldn't be changing on every window, just the ones that have a different behavior. Maybe my solution isn't the right one. I like the back and forth on the topic here though, because it is an issue.
If I was running 10.4, I'd definitely be giving this a go.
PathFinder is probably the best alternative Finder but it's too slow for me. When I can do file operations in the blink of an eye in the terminal, I should be able to get close in a file browser app. If not then it's wasting time doing something I don't need it to do. When I'm trying to sort through thousands of files, I can't be doing with all the delays.
Sadly that seems to have happened a lot to OS X. Yes it's pretty but there are times I just feel I want to get at some raw power.
For the most part, I don't have much of a problem with the Finder but it lacks features and it is buggy. Imagine if the Finder was just an open source front-end to the unix base. We could all have tabbed views by now. I wonder why Apple just don't open source it or I mean start an open source project to make a better Finder.
I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
cadaver (GPL command line WebDAV client) is 1000x faster and way better threaded than iDisk.
Also, and I've stated this many times before, a virtual file system such as Gnome's. With the Gnome VFS you can mount (eg) an FTP volume and browse it as an extension of your hard disk, copying files to and from it, opening files on it with your local apps (instead of launching <networking app x>, downloading the file first, etc).
Think iDisk behaviour, but for every form of networked storage. Double click an icon in your home folder that represents some form of networked storage, and start browsing. Add it to the left hand tab of the finder's window.
I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
Allowing people to browse zip files like they were folders brings a lot of usability problems and confusion to newbie users. Instead of unzipping a file, a newbie user will simply try to run apps or manipulate files inside the zip file as though it were in a folder.
And that just doesn't work.
A lot of apps just can't run or run correctly within a zip file. Adding this feature to the Finder is a disaster waiting to strike a poor n00b.
But, yes, we can all agree that the Finder is a crusty old bag of shit.
I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
I've actually wanted to browse compressed archives too. If you can't do stuff with the files like kim kap sol said then that would be a limitation but maybe there could be a scrollable preview window that lists the contents and lets you extract selections.
Quote:
Originally posted by 1337_5L4Xx0R
Also, and I've stated this many times before, a virtual file system such as Gnome's. With the Gnome VFS you can mount (eg) an FTP volume and browse it as an extension of your hard disk, copying files to and from it, opening files on it with your local apps (instead of launching <networking app x>, downloading the file first, etc).
Tiger mounts ftp servers when you click an ftp link from Safari whereas Panther just downloaded the file. That actually annoyed me but only because OS X sometimes takes so long to mount the thing. As you say, using some of the unix tools would likely speed this up enormously as they are tried and tested.
In Tiger, I can use the connect to server option to access the ftp account for my website. I just type in the ftp server address, login/pass and it mounts where my other drives are in the Finder.
How about a plugin architecture for the new, leaner, meaner heavily threaded Finder? That way programmers can compensate for Apple's shortcomings wrt FTFF. The finder could be the next killer app, instead of a crusty bag of crap.
Comments
Originally posted by JeffDM
Most of the programs that do this don't really seem to have a reason to keep running. If you still want to use the program later in a session, it seems to be much quicker to hide and unhide apps than it is to close a window and re open it.
Some apps, such as iTunes, have lower CPU usage with no windows open (whether those apps are hidden or not). Also, it is totally inconsistent. Why should the user have to remember which apps quit when you close the last window, and which don't? For example, Address book stays open when you close its window, but calculator does not. In order to fix the consistency problem, I'd much rather that things change to all apps staying open until you choose "quit" than all apps quitting when you close their final window.
Excellent use cases can be provided for both types of behavior, and IMHO this 'inconsistency' does little if any harm to users. The simple cases - iPhoto, PhotoBooth - *are* simple, while more complex cases - mulitple window/document apps, Adress Book - aren't, and necessarily so. Shoehorning everything into a single model would eliminate the simple cases and possibly introduce greater complexity in the long run via complex corner cases. For strawman examples to the contrary, witness the disaster that is MS Word's "what will this 'X' button do?" MDI-bastard-child interface on Windows.
So I think Apple is being open-minded and possibly even forward-looking. Eventually, I suspect we'll see the notion of 'Quit' or process termination removed from interface vocabulary altogether. Applications will always maintain a user's working state and won't ever terminate or quit - they'll simply suspend to virtual memory. The processes will automatically come and go as the app and OS deem necessary.
If you have enough RAM, OS X functions much this way already; just leave everything running. At this point the only compelling (inteface) rationale for 'Quitting' is to free up the dock and return its icons to a reasonable size - solely an interface contrivance, to be sure.
Originally posted by blue2kdave
I said this before and got no responses, but wouldn't it be easy to make applications that quit upon closing a window have a square red button instead of a round one? Instant feedback on what will happen.
If you are going to keep some apps quitting upon closure of final window, and some not, this is the obvious solution. I have no idea why Apple doesn't do it or something similar.
Originally posted by dglow
Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?
Don't even need to know?? I think it's important that users know whether an app is going to quit or not when they perform a particular action.
Originally posted by Mr. H
10. Shift-arrow selection behaviour. Like someone else said, this is not limited to the Finder, but is worth mentioning because it is IMHO the single most annoying thing in OS X. It really pisses me off. Really.
\tUsing iTunes as an example: In an iTunes playlist, multiple tracks can be selected by clicking on a track, then holding down the shift key whilst pressing the up/down arrow keys.
\tPressing the down arrow key always extends the selection downwards, whilst pressing the up arrow key always extends the selection upwards. This means that it is impossible to contract your selection, you can only make it bigger.
\tI find this highly annoying and think that the selection process should work like selection of text in other applications such as TextEdit. This would make the interface more consistent and more intuitive. The function of the up/down arrow keys should depend on the direction in which the selection was originally extended.
\tFor example, imagine wanting to make a selection starting at a particular song and extending downwards: if you overshoot your intended selection, you should be able to contract the selection by pressing the up arrow key. Correspondingly, if your original selection was upwards, pressing the down arrow key should then contract the selection.
You use the cmd (Apple) key for that. I always combine two keys for selections, cmd for single or selective selections, shift for filing the gaps if neccessary. It works, but most people don't know you can use cmd for it. And I'm not sure if the use of the cmd-key is a consistent or logical UI feature for this.
Originally posted by BigBlue
You use the cmd (Apple) key for that. I always combine two keys for selections, cmd for single or selective selections, shift for filing the gaps if neccessary. It works, but most people don't know you can use cmd for it. And I'm not sure if the use of the cmd-key is a consistent or logical UI feature for this.
No, you can't. You have misunderstood.
Do this: Open a folder that contains several items in the Finder, and set it to list view. Now, select one of the items in the middle. Now hold down the shift key, and press the down arrow. Keeping the shift key held down, every time you press the down arrow, the selection will extend downwards. There is no way to contract the selection. If you press the up arrow, the selection will extend upwards.
Do the same in text edit when selecting text and you will notice different, and much more intuitive behaviour.
Originally posted by Mr. H
Don't even need to know?? I think it's important that users know whether an app is going to quit or not when they perform a particular action.
Yes, I would argue (and do so, above) that we will soon reach a point where users will neither have to know nor care whether an application is 'running' or not. But, granted, that time has not yet arrived.
"Is it important that users know whether or not an app will quit when they perform a particular action?" (specifically, clicking the red 'X' button)
No, it is not. As long as that action does not result in loss of user data or other relevant state, it is not important. *Certainly* not important enough to introduce an interface curiosity whereby some 'X' buttons are shaped differently than others... talk about inconsistency!
Now, let's try a slightly different question: is it important that users know whether or not an app has quit in response to a particular action? For the sake of this argument, sure. Look at the menu bar; is the app's name there? Check the dock; can you find its icon?
My point: there is no need to know 'in advance' exactly what the close button will do, so long as it doesn't do anything 'bad' *and*, if you're an individual who happens to care, there are means for determining the result after the fact. If you care, and an app's close button behaves consistently, you will quickly learn its behavior.
Originally posted by dglow
My point: there is no need to know 'in advance' exactly what the close button will do, so long as it doesn't do anything 'bad' *and*, if you're an individual who happens to care, there are means for determining the result after the fact. If you care, and an app's close button behaves consistently, you will quickly learn its behavior.
Are you trying to tell me it's not a pain when an Application quits when you are not expecting it to?
I agree that making the round widget square would probably be going too far, and that's why I said "or something similar" would be a good idea. If the app is going to quit, the "x" that appears inside the circle could be itself enclosed in a square. This would give the user some advance warning that pressing the widget will result in the application quitting.
There are some applications which people do not use very often, and it is therefore easy to forget whether it is an app that quits upon closure of final window or not. Also, the application may have been updated (as part of an OS update for example) since the last time you used it, and its behaviour in this regard may have changed. Some visual indicator of what is about to happen would be nice.
It is important to note that I don't think this a major problem, mac os is not doomed because of this flaw. It is just one of those "little things" that would be nice if it were fixed.
Originally posted by dglow
..."Is it important that users know whether or not an app will quit when they perform a particular action?" (specifically, clicking the red 'X' button)
No, it is not. As long as that action does not result in loss of user data or other relevant state, it is not important. *Certainly* not important enough to introduce an interface curiosity whereby some 'X' buttons are shaped differently than others... talk about inconsistency!
...
Actually, i like what you are proposing.
Generally, I do understand theoretically why there is some
different behavior regarding on clicking the red X button.
(1) Apps, which create and manage docs (content) do not quit by clicking
the red X. A no brainer.
(2) Apps, which are single window apps like System Prefpane, Calculator
and some other quit on clicking.
But i do not agree the philosophy behind that. I think it is a flaw
in UI design, yes, ... talk about inconsistency!
I am always asking myself, why the very same action (clicking the red X)
produces different results (either quit or close). No big deal, but
the inconsistency does exist. MS Windows produces more consistency
in this regard.
I belong to that specie that never ever quit any app, i almost always
use CMD-H. I just want to have my apps steadily on standby. I feel
more comfortable that way.
As a sidenote: in the Mac OS 8/9 days, hiding an app gave us
a huge speed advantage over MS Windows, remember.
Opening a large PS doc was almost instantly, just because the
app was already running in the b.g.
I think that with that approach, you could very quickly design a fully functional, stable, lightweight, multi-threaded finder. It would also tie in much better with terminal commands as it would just be using the same commands itself. If it was mostly done in some sort of scripting way, it could be more easily customized by end users too and that would also speed up development.
I also wouldn't mind seeing some sort of revolutionary file viewing feature. The column view is my favourite of all of the 3 we have but it still has that sliding problem when moving files. Since Spotlight indexes a lot of the filesystem, I wonder if it would be possible to have a big window that displayed every folder in the entire filesystem at once as some sort of tree view. This view would encourage users to have a more ordered filesystem. Often times I see people store lots of files on the desktop and then put one or two files 20 hierarchies deep. That makes finding the files you want inefficient.
Obviously with so many folders in an OS X system, the window would need to have a zoom function (preferrably with the mouse wheel and +/- buttons for users of crappy mice
Lastly, I think it would be good to have the Finder always accessible without switching the current application to the background. Maybe if there was a menu item like spotlight that dropped down the file browser. One use I could see is for dragging images out of Safari. You can drop images straight into your filesystem.
just then click on the app and there you are.
Saves a lot of real estate and makes things look a whole lot better.
Originally posted by Marvin
I don't like the Finder very much either. One thing that I keep thinking though is why would it be so hard to make a new one?
Path Finder 4
If I was running 10.4, I'd definitely be giving this a go.
Originally posted by dglow
Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?
It wouldn't be changing on every window, just the ones that have a different behavior. Maybe my solution isn't the right one. I like the back and forth on the topic here though, because it is an issue.
Originally posted by Mr. H
Path Finder 4
If I was running 10.4, I'd definitely be giving this a go.
PathFinder is probably the best alternative Finder but it's too slow for me. When I can do file operations in the blink of an eye in the terminal, I should be able to get close in a file browser app. If not then it's wasting time doing something I don't need it to do. When I'm trying to sort through thousands of files, I can't be doing with all the delays.
Sadly that seems to have happened a lot to OS X. Yes it's pretty but there are times I just feel I want to get at some raw power.
For the most part, I don't have much of a problem with the Finder but it lacks features and it is buggy. Imagine if the Finder was just an open source front-end to the unix base. We could all have tabbed views by now. I wonder why Apple just don't open source it or I mean start an open source project to make a better Finder.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
cadaver (GPL command line WebDAV client) is 1000x faster and way better threaded than iDisk.
Also, and I've stated this many times before, a virtual file system such as Gnome's. With the Gnome VFS you can mount (eg) an FTP volume and browse it as an extension of your hard disk, copying files to and from it, opening files on it with your local apps (instead of launching <networking app x>, downloading the file first, etc).
Think iDisk behaviour, but for every form of networked storage. Double click an icon in your home folder that represents some form of networked storage, and start browsing. Add it to the left hand tab of the finder's window.
Originally posted by 1337_5L4Xx0R
I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
Allowing people to browse zip files like they were folders brings a lot of usability problems and confusion to newbie users. Instead of unzipping a file, a newbie user will simply try to run apps or manipulate files inside the zip file as though it were in a folder.
And that just doesn't work.
A lot of apps just can't run or run correctly within a zip file. Adding this feature to the Finder is a disaster waiting to strike a poor n00b.
But, yes, we can all agree that the Finder is a crusty old bag of shit.
Originally posted by 1337_5L4Xx0R
I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.
I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?
I've actually wanted to browse compressed archives too. If you can't do stuff with the files like kim kap sol said then that would be a limitation but maybe there could be a scrollable preview window that lists the contents and lets you extract selections.
Originally posted by 1337_5L4Xx0R
Also, and I've stated this many times before, a virtual file system such as Gnome's. With the Gnome VFS you can mount (eg) an FTP volume and browse it as an extension of your hard disk, copying files to and from it, opening files on it with your local apps (instead of launching <networking app x>, downloading the file first, etc).
Tiger mounts ftp servers when you click an ftp link from Safari whereas Panther just downloaded the file. That actually annoyed me but only because OS X sometimes takes so long to mount the thing. As you say, using some of the unix tools would likely speed this up enormously as they are tried and tested.
In Tiger, I can use the connect to server option to access the ftp account for my website. I just type in the ftp server address, login/pass and it mounts where my other drives are in the Finder.
Marvin, Finder's FTP is a joke.
and on the subject of virtual file systems, peep this: http://flickrfs.sourceforge.net/