Safari does have that, it just has to be turned on. In the Advanced tab of Safari preferences select "show develop menu in menu bar" and quit and relaunch Safari. Now when you right click on an image there is "Inspect Element" option.
Thanks, another one to tick off! Now all I need are MeasureIt and WeatherForcast for Safari! I use Safari 95% of the time but Firefox has some nice features, too!
No, I'm sure it will perform like a dog and you'll have to resign yourself to using your shiny new aluminium as a glorified paperweight.... hehe....seriously though.... Sorry I'm not normally this nass-tee
Quote:
Originally Posted by Tauron
Will Snow Leopard run super fast on the new macbook pros with nvidia gpus?
No disrespect to all you recent converts out there, but the so call 'new feature' that you are calling Image Boot is not new at all.
The Fact is that you could do that in Mac OS 6.x - 9.x ... they just never got it into X yet.
What!?! Either you were so bored you thought you'd be funny or you're just plain ill-informed.
The feature uses capabilities within Apple's implementation of EFI, found only in the hardware of Intel-based Macs. It involves the bless command and the options are available to EFI-based systems only and are not present in Open Firmware on PPC-based systems.
Also as previously posted, this article has got the "Image Boot" capability wrong. It's no Mac hypervisor. It's operable only for read-only boot sources like an install DVD image. It's not new to Snow Leopard. The capability is also there for Leopard's bless command too. I haven't attempted it with Tiger for Intel as I no longer use that release.
No, I'm sure it will perform like a dog and you'll have to resign yourself to using your shiny new aluminium as a glorified paperweight.... hehe....seriously though.... Sorry I'm not normally this nass-tee
The MacBook Pro hardware design has been motivated by the direction of Snow Leopard, which includes the capability to utilise GPU cores for processing. I haven't got confirmation of this yet, but it's possible the Snow Leopard will be able to utilise both GPUs for processing... making it essentially a 'Quad-core' notebook. Snow Leopard will run amazingly well on these systems despite being one year old by the time Snow Leopard ships.
By that time though we'll have MacBook Pros featuring Nehelem processors which feature hyperthreading. So your average MacBook Pro (Late 2009) will feature a minimum of 6 processing cores (four physical and two virtual). Quad-core mobile Nehelems may also be added by Apple making that 10 processing cores. SSDs will be more affordable and hence more common. 2009 is going to be an exciting year for performance.
It's the view in the middle of the workspace manager window. One can drag-n-drop files/folders up the directory tree, or place it on the Shelf near the top to move/copy to another destination not in view. NEXTSTEP wasn't perfect by any means, but the what you see in Mac OS X today is a completely broken version of this. They should have at least copied it properly.
A rewritten Finder using Cocoa will be very interesting to see. If they are indeed doing it in 100% Cocoa, a lot of things could be cleaned up, but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
... but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
Yup...you can be 99% sure this is what Apple is doing.
For you CUT and Paste people I have an idea. If you right click on a file you will get a choice (in the context menu) of "Move To Trash". I say make it more like "Move To", much like "Open With". You would be given a default set of choices, and also be able to select "Other" and browse to the location you like that particular file.
My objection is that putting a move operation under the guise of cut and paste is a poor solution. In addition, moving files can cause data loss in specific situations. Since it's not clear if a cut and paste would result in a rename or a move operation, the user might be unintentionally or unknowing exposing themselves to a risk.
I've seen it happen several times. Aborting a copy of a 2000 picture iPhoto library to your external drive can leave half of the files spread across two different volumes. If a firwire or USB cable is accidentally removed, there is a chance for data loss. But if it's rename, you can undo it in an instant. This is highly inconsistent.
Even if you're highly experienced user, you still have to stop and think to determine if a cut and paste will result in a move or a rename based on the source and destination. This has bad UI design written all over it.
Drag and drop is always a copy unless you hold down a special key. And even then the cursor changes to show you if it will be a move or a copy. This is a constant behavior. However, you can't indicate what will happen when you invoke a keyboard shortcut. It's just not obvious what will occur.
Again moving is not copying. The implications are significantly different. And, since it's not obvious as to what will occur when invoked, using cut and paste for files is a poor metaphor.
Because "pick up and drop" doesn't make it any more obvious if a rename or move will occur than "cut and paste."
You don't have to worry about loosing text when you copy and paste in a word processor. Why should you expect complications when using cut and paste with files?
Until Apple can figure out a technical solution that makes cut and paste behave in a consistent way that is undoable, I wouldn't hold my breath.
OK I know I'm late to the party with my comment two days after my previous one, but anyway:
First of all, your differenciation of Cut&Paste as a Rename vs. a Move is, from a user's point of view, totally artificial and does not make any sense. The user does not care at all if it's either or the other, the effect is the same, ie the file being taken away from one location and stored in the other. Both can be undone, and if undoing takes a blink of an eye or a fraction of a second doesn't matter. As Cut&Paste=Move only deletes the directory entry on the source drive, it can be undone as easily as a rename. So the basis of all your following arguments is severely flawed.
Then, honestly, I can't see how using Cut&Paste is any different from moving a file with the mouse. Try moving with the mouse and the firewire connection breaks. You end up with half the files on one drive and half the files on the other. At least under Windows, I can undo the action within a fraction of a second. As a user, I don't care at all if the copy&paste is technically done with a move or a copy, delete, paste. Any potential loss of files would be only owed to bad implementation as the file should be copied first and deleted only after the copying was successful.
Of course there is the question of implementation: Either Cut deletes the original file immediately (similar to Cut in a word processor) and pastes it only later and only if requested to do so. In this implementation, there is a risk of data loss if you Cut/Copy some more files AND only have a single 'clipboard'. This is the way word processors work, and quite apparently and contrary to what you say you DO face the risk of losing data. Quite on the contrary, to avoid that risk, Cut&Paste is usually implemented differently, ie cut does not delete before a Paste is used. This admittedly is inconsistent with Cut&Paste in word processors because Cutting does not delete anything if you forget about it and revert to some other task before pasting, but for good reason. If you prefer consistency, then go the other way and face the risk (don't know of any actual implementation, though). But I trust that the vast majority would vote that breaking with the metaphor here is a good idea, and the inconsistency is negligible compared to all the other breaks of the desktop metaphor there are. And for the avoidance of doubt: almost all such breaks of the metaphor are there for very good reason, because most of the advantages of the computer over old-fashioned handwriting and moving papers around lie in such breaks of the metaphor.
By the way, is dragging with the mouse always a Copy? In Windows, it's Move if it's on the same drive, and Copy if it's on different drives.
OK I know I'm late to the party with my comment two days after my previous one, but anyway:
First of all, your differenciation of Cut&Paste as a Rename vs. a Move is, from a user's point of view, totally artificial and does not make any sense. The user does not care at all if it's either or the other, the effect is the same, ie the file being taken away from one location and stored in the other. Both can be undone, and if undoing takes a blink of an eye or a fraction of a second doesn't matter. As Cut&Paste=Move only deletes the directory entry on the source drive, it can be undone as easily as a rename. So the basis of all your following arguments is severely flawed.
Then, honestly, I can't see how using Cut&Paste is any different from moving a file with the mouse. Try moving with the mouse and the firewire connection breaks. You end up with half the files on one drive and half the files on the other. At least under Windows, I can undo the action within a fraction of a second. As a user, I don't care at all if the copy&paste is technically done with a move or a copy, delete, paste. Any potential loss of files would be only owed to bad implementation as the file should be copied first and deleted only after the copying was successful.
Of course there is the question of implementation: Either Cut deletes the original file immediately (similar to Cut in a word processor) and pastes it only later and only if requested to do so. In this implementation, there is a risk of data loss if you Cut/Copy some more files AND only have a single 'clipboard'. This is the way word processors work, and quite apparently and contrary to what you say you DO face the risk of losing data. Quite on the contrary, to avoid that risk, Cut&Paste is usually implemented differently, ie cut does not delete before a Paste is used. This admittedly is inconsistent with Cut&Paste in word processors because Cutting does not delete anything if you forget about it and revert to some other task before pasting, but for good reason. If you prefer consistency, then go the other way and face the risk (don't know of any actual implementation, though). But I trust that the vast majority would vote that breaking with the metaphor here is a good idea, and the inconsistency is negligible compared to all the other breaks of the desktop metaphor there are. And for the avoidance of doubt: almost all such breaks of the metaphor are there for very good reason, because most of the advantages of the computer over old-fashioned handwriting and moving papers around lie in such breaks of the metaphor.
By the way, is dragging with the mouse always a Copy? In Windows, it's Move if it's on the same drive, and Copy if it's on different drives.
You've just hown world that some people do care how it's implemented and that some people don't care. And that some people do care about the metaphors and that others don't. You've effectively discovered that people have...*gasp*...DIFFERENT OPINIONS!!! WOW! This is a brand new revelation that will surely revolutionize how we see the world.
Copy/pasting files is a moot subject though...it's based on a file system structure of the 70s where location of files matters. Location of files doesn't matter anymore even though some people truly believe it does.
If we were still in a world where searching for a file took minutes or hours, then a hierarchical file system would make a lot of sense. But we don't.
But like I said...opinions.
Like kids fighting to establish whether one presidential candidate is better than another, is better, or whether one religion is better than another, or whether one file system cut/paste implementation is better than another, I sit in looking at them shaking my head because I know it simply is irrelevant. They are all based on broken systems.
I think it's rather inconsistent. You can't copy-passte in Finder, how stupid is that?
Also, I don't see why BlueTooth has it's own little app and can't be directly included into Finder. I'd like to see my BlueTooth cellphone show up in Finder's left column.
It's the view in the middle of the workspace manager window. One can drag-n-drop files/folders up the directory tree, or place it on the Shelf near the top to move/copy to another destination not in view. NEXTSTEP wasn't perfect by any means, but the what you see in Mac OS X today is a completely broken version of this. They should have at least copied it properly.
A rewritten Finder using Cocoa will be very interesting to see. If they are indeed doing it in 100% Cocoa, a lot of things could be cleaned up, but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
They've had a Cocoa Finder ready to go since 1998. The problem was first Classic, then Carbon and now that both are getting their property burials a modernized version of that code base most certainly will have matured over the years since I left Apple.
And NeXTSTEP was a decade ahead of it's time. They screwed it up with OS X.
Comments
Safari does have that, it just has to be turned on. In the Advanced tab of Safari preferences select "show develop menu in menu bar" and quit and relaunch Safari. Now when you right click on an image there is "Inspect Element" option.
Thanks, another one to tick off! Now all I need are MeasureIt and WeatherForcast for Safari! I use Safari 95% of the time but Firefox has some nice features, too!
Will Snow Leopard run super fast on the new macbook pros with nvidia gpus?
No disrespect to all you recent converts out there, but the so call 'new feature' that you are calling Image Boot is not new at all.
The Fact is that you could do that in Mac OS 6.x - 9.x ... they just never got it into X yet.
What!?!
The feature uses capabilities within Apple's implementation of EFI, found only in the hardware of Intel-based Macs. It involves the bless command and the options are available to EFI-based systems only and are not present in Open Firmware on PPC-based systems.
Also as previously posted, this article has got the "Image Boot" capability wrong. It's no Mac hypervisor. It's operable only for read-only boot sources like an install DVD image. It's not new to Snow Leopard. The capability is also there for Leopard's bless command too. I haven't attempted it with Tiger for Intel as I no longer use that release.
No, I'm sure it will perform like a dog and you'll have to resign yourself to using your shiny new aluminium as a glorified paperweight....
The MacBook Pro hardware design has been motivated by the direction of Snow Leopard, which includes the capability to utilise GPU cores for processing. I haven't got confirmation of this yet, but it's possible the Snow Leopard will be able to utilise both GPUs for processing... making it essentially a 'Quad-core' notebook. Snow Leopard will run amazingly well on these systems despite being one year old by the time Snow Leopard ships.
By that time though we'll have MacBook Pros featuring Nehelem processors which feature hyperthreading. So your average MacBook Pro (Late 2009) will feature a minimum of 6 processing cores (four physical and two virtual). Quad-core mobile Nehelems may also be added by Apple making that 10 processing cores. SSDs will be more affordable and hence more common. 2009 is going to be an exciting year for performance.
Yeah. The non-snappiness of the browser essentially broke the usability of it. Oh, and the lack of the bread crumb and Shelf, but what can you do.
Lack of bread crumb? View > Show Path Bar
Lack of bread crumb? View > Show Path Bar
If it is not specifically called a breadcrumb...then it cannot be one.
Wow... I can't believe I never saw that... I feel like such an idiot now... don't see why it needs its own separator line though
Still, Finder is subpar compared to iPhoto, KeyNote or iCal just to name a few...
Lack of bread crumb? View > Show Path Bar
It's the view in the middle of the workspace manager window. One can drag-n-drop files/folders up the directory tree, or place it on the Shelf near the top to move/copy to another destination not in view. NEXTSTEP wasn't perfect by any means, but the what you see in Mac OS X today is a completely broken version of this. They should have at least copied it properly.
A rewritten Finder using Cocoa will be very interesting to see. If they are indeed doing it in 100% Cocoa, a lot of things could be cleaned up, but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
... but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
Yup...you can be 99% sure this is what Apple is doing.
See I knew I could make it more.... "Macish"
Please listen carefully.
My objection is that putting a move operation under the guise of cut and paste is a poor solution. In addition, moving files can cause data loss in specific situations. Since it's not clear if a cut and paste would result in a rename or a move operation, the user might be unintentionally or unknowing exposing themselves to a risk.
I've seen it happen several times. Aborting a copy of a 2000 picture iPhoto library to your external drive can leave half of the files spread across two different volumes. If a firwire or USB cable is accidentally removed, there is a chance for data loss. But if it's rename, you can undo it in an instant. This is highly inconsistent.
Even if you're highly experienced user, you still have to stop and think to determine if a cut and paste will result in a move or a rename based on the source and destination. This has bad UI design written all over it.
Drag and drop is always a copy unless you hold down a special key. And even then the cursor changes to show you if it will be a move or a copy. This is a constant behavior. However, you can't indicate what will happen when you invoke a keyboard shortcut. It's just not obvious what will occur.
Again moving is not copying. The implications are significantly different. And, since it's not obvious as to what will occur when invoked, using cut and paste for files is a poor metaphor.
Because "pick up and drop" doesn't make it any more obvious if a rename or move will occur than "cut and paste."
You don't have to worry about loosing text when you copy and paste in a word processor. Why should you expect complications when using cut and paste with files?
Until Apple can figure out a technical solution that makes cut and paste behave in a consistent way that is undoable, I wouldn't hold my breath.
OK I know I'm late to the party with my comment two days after my previous one, but anyway:
First of all, your differenciation of Cut&Paste as a Rename vs. a Move is, from a user's point of view, totally artificial and does not make any sense. The user does not care at all if it's either or the other, the effect is the same, ie the file being taken away from one location and stored in the other. Both can be undone, and if undoing takes a blink of an eye or a fraction of a second doesn't matter. As Cut&Paste=Move only deletes the directory entry on the source drive, it can be undone as easily as a rename. So the basis of all your following arguments is severely flawed.
Then, honestly, I can't see how using Cut&Paste is any different from moving a file with the mouse. Try moving with the mouse and the firewire connection breaks. You end up with half the files on one drive and half the files on the other. At least under Windows, I can undo the action within a fraction of a second. As a user, I don't care at all if the copy&paste is technically done with a move or a copy, delete, paste. Any potential loss of files would be only owed to bad implementation as the file should be copied first and deleted only after the copying was successful.
Of course there is the question of implementation: Either Cut deletes the original file immediately (similar to Cut in a word processor) and pastes it only later and only if requested to do so. In this implementation, there is a risk of data loss if you Cut/Copy some more files AND only have a single 'clipboard'. This is the way word processors work, and quite apparently and contrary to what you say you DO face the risk of losing data. Quite on the contrary, to avoid that risk, Cut&Paste is usually implemented differently, ie cut does not delete before a Paste is used. This admittedly is inconsistent with Cut&Paste in word processors because Cutting does not delete anything if you forget about it and revert to some other task before pasting, but for good reason. If you prefer consistency, then go the other way and face the risk (don't know of any actual implementation, though). But I trust that the vast majority would vote that breaking with the metaphor here is a good idea, and the inconsistency is negligible compared to all the other breaks of the desktop metaphor there are. And for the avoidance of doubt: almost all such breaks of the metaphor are there for very good reason, because most of the advantages of the computer over old-fashioned handwriting and moving papers around lie in such breaks of the metaphor.
By the way, is dragging with the mouse always a Copy? In Windows, it's Move if it's on the same drive, and Copy if it's on different drives.
OK I know I'm late to the party with my comment two days after my previous one, but anyway:
First of all, your differenciation of Cut&Paste as a Rename vs. a Move is, from a user's point of view, totally artificial and does not make any sense. The user does not care at all if it's either or the other, the effect is the same, ie the file being taken away from one location and stored in the other. Both can be undone, and if undoing takes a blink of an eye or a fraction of a second doesn't matter. As Cut&Paste=Move only deletes the directory entry on the source drive, it can be undone as easily as a rename. So the basis of all your following arguments is severely flawed.
Then, honestly, I can't see how using Cut&Paste is any different from moving a file with the mouse. Try moving with the mouse and the firewire connection breaks. You end up with half the files on one drive and half the files on the other. At least under Windows, I can undo the action within a fraction of a second. As a user, I don't care at all if the copy&paste is technically done with a move or a copy, delete, paste. Any potential loss of files would be only owed to bad implementation as the file should be copied first and deleted only after the copying was successful.
Of course there is the question of implementation: Either Cut deletes the original file immediately (similar to Cut in a word processor) and pastes it only later and only if requested to do so. In this implementation, there is a risk of data loss if you Cut/Copy some more files AND only have a single 'clipboard'. This is the way word processors work, and quite apparently and contrary to what you say you DO face the risk of losing data. Quite on the contrary, to avoid that risk, Cut&Paste is usually implemented differently, ie cut does not delete before a Paste is used. This admittedly is inconsistent with Cut&Paste in word processors because Cutting does not delete anything if you forget about it and revert to some other task before pasting, but for good reason. If you prefer consistency, then go the other way and face the risk (don't know of any actual implementation, though). But I trust that the vast majority would vote that breaking with the metaphor here is a good idea, and the inconsistency is negligible compared to all the other breaks of the desktop metaphor there are. And for the avoidance of doubt: almost all such breaks of the metaphor are there for very good reason, because most of the advantages of the computer over old-fashioned handwriting and moving papers around lie in such breaks of the metaphor.
By the way, is dragging with the mouse always a Copy? In Windows, it's Move if it's on the same drive, and Copy if it's on different drives.
You've just hown world that some people do care how it's implemented and that some people don't care. And that some people do care about the metaphors and that others don't. You've effectively discovered that people have...*gasp*...DIFFERENT OPINIONS!!! WOW! This is a brand new revelation that will surely revolutionize how we see the world.
Copy/pasting files is a moot subject though...it's based on a file system structure of the 70s where location of files matters. Location of files doesn't matter anymore even though some people truly believe it does.
If we were still in a world where searching for a file took minutes or hours, then a hierarchical file system would make a lot of sense. But we don't.
But like I said...opinions.
Like kids fighting to establish whether one presidential candidate is better than another, is better, or whether one religion is better than another, or whether one file system cut/paste implementation is better than another, I sit in looking at them shaking my head because I know it simply is irrelevant. They are all based on broken systems.
I think it's rather inconsistent. You can't copy-passte in Finder, how stupid is that?
Also, I don't see why BlueTooth has it's own little app and can't be directly included into Finder. I'd like to see my BlueTooth cellphone show up in Finder's left column.
You can copy and paste items in leopard finder.
It's the view in the middle of the workspace manager window. One can drag-n-drop files/folders up the directory tree, or place it on the Shelf near the top to move/copy to another destination not in view. NEXTSTEP wasn't perfect by any means, but the what you see in Mac OS X today is a completely broken version of this. They should have at least copied it properly.
A rewritten Finder using Cocoa will be very interesting to see. If they are indeed doing it in 100% Cocoa, a lot of things could be cleaned up, but I'm guessing they are just going to take the existing Carbon C++ backend and wrap the UI layers with Cocoa. There won't be that many changes if they did that.
They've had a Cocoa Finder ready to go since 1998. The problem was first Classic, then Carbon and now that both are getting their property burials a modernized version of that code base most certainly will have matured over the years since I left Apple.
And NeXTSTEP was a decade ahead of it's time. They screwed it up with OS X.