111–120 of 127 posts
IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all the design details that annoy me?
Earlier quoted context omitted.
Lion lets you move copied files by adding option to your paste: option-command-V.
Where did you learn that? (Honest question, I thought I'd read through most new features before I upgraded to Lion.)
I am a software engineer who works mainly on a Mac. I am fully aware of the existence of .DS_Store files, but it has never bothered me nearly as much as it bothers this guy. IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all t…
Whether or not I agree with his choice to disable .DS_Store (isn't that _his_ decision, and we can just leave it be?) -- I am totally amazed at his persistence, and eventual success, to implement what he wants. The level of sophistication to live-patch a framework using mach_star is far beyond your ordinary level of interaction with the O.S. Forget about the non-portability or possible breakage on an update, this is _hacking_!
So I disagree with your rejoinder: how about you find a reasonably permanent solution to turning off .DS_Store?
Earlier quoted context omitted.
Lion lets you move copied files by adding option to your paste: option-command-V.
Which is the dumbest way to fix this issue: 1. You have to remember a new shortcut 2. If you forget and you paste with Cmd-V thinking that you did Cmd-X to cut, you end up copying the files, so you have to go back, re-select them, and delete them manually. I just can't possibly understand _why_ they would explicitly think: "no, let's not use the standard user interaction here".
Apple's way puts a burden on the user of remembering a different menu item/key combo, but doesn't break the similarity of the cut/copy/paste interactions with those in the rest of the system. They've just chosen a different set of tradeoffs than Windows did for this engineering problem.
Earlier quoted context omitted.
Which is the dumbest way to fix this issue: 1. You have to remember a new shortcut 2. If you forget and you paste with Cmd-V thinking that you did Cmd-X to cut, you end up copying the files, so you have to go back, re-select them, and delete them manually. I just can't possibly understand _why_ they would explicitly think: "no, let's not use the standard user interaction here".
Because in some subtle ways, it's very different from the standard user interaction — if one cuts a piece of text from a TextEdit document, that text disappears immediately. That seems undesirably unsafe in a file system explorer, though, which is why Windows doesn't delete a file that's been cut in Explorer unless and until it actually gets pasted somewhere else. This puts a burden on the user to remember that a see…
MS Office does not have a proper clipboard, either. For example, in Excel, open-select-cut-close-paste does not do what one expects:
- cut does not delete data from the clipboard, but sort-of marks it for a future move.
- close makes the app forget about that move, clearing the clipboard.
- because the clipboard is empty, paste does nothing.
IIRC, the clipboard is even broken within a single document, but I do not remember details (something like cut-enter data in a cell-select destination-paste?)
I am a software engineer who works mainly on a Mac. I am fully aware of the existence of .DS_Store files, but it has never bothered me nearly as much as it bothers this guy. IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all t…
I am also a software engineer who works mainly on a Mac. Whether or not I agree with his choice to disable .DS_Store (isn't that _his_ decision, and we can just leave it be?) -- I am totally amazed at his persistence, and eventual success, to implement what he wants. The level of sophistication to live-patch a framework using mach_star is far beyond your ordinary level of interaction with the O.S. Forget about the no…
Earlier quoted context omitted.
Which is the dumbest way to fix this issue: 1. You have to remember a new shortcut 2. If you forget and you paste with Cmd-V thinking that you did Cmd-X to cut, you end up copying the files, so you have to go back, re-select them, and delete them manually. I just can't possibly understand _why_ they would explicitly think: "no, let's not use the standard user interaction here".
Because in some subtle ways, it's very different from the standard user interaction — if one cuts a piece of text from a TextEdit document, that text disappears immediately. That seems undesirably unsafe in a file system explorer, though, which is why Windows doesn't delete a file that's been cut in Explorer unless and until it actually gets pasted somewhere else. This puts a burden on the user to remember that a see…
I'm actually not sure why anyone would defend the Apple way of doing this -- it's truly baffling. Windows has some terrible conventions and Apple has some terrible conversions -- we'd all be better off choosing the best of both then blindly defending one over the other.
Earlier quoted context omitted.
Which is the dumbest way to fix this issue: 1. You have to remember a new shortcut 2. If you forget and you paste with Cmd-V thinking that you did Cmd-X to cut, you end up copying the files, so you have to go back, re-select them, and delete them manually. I just can't possibly understand _why_ they would explicitly think: "no, let's not use the standard user interaction here".
Because in some subtle ways, it's very different from the standard user interaction — if one cuts a piece of text from a TextEdit document, that text disappears immediately. That seems undesirably unsafe in a file system explorer, though, which is why Windows doesn't delete a file that's been cut in Explorer unless and until it actually gets pasted somewhere else. This puts a burden on the user to remember that a see…