[d00d]

In reply to:

---

If i cut a different object without executing a paste command from a previous cut, the os should fuggetaboutit and work with me. no corruption, no lost files, just don't do anything and move on.

---

So, you're talking about the implementation I mentioned earlier where it places the file back where it was originally. This is inconsistent. If you cut text, then cut some other text, does the original text get put back? No, it doesn't. That's not cut behavior.

In reply to:

---

Or, dare I say it, let there be more than one clipboard. one for files, one for text. I have never lost a file in windows cutting it, not pasting it and then cutting text.

---

How about one for pictures? Movies too? That way, the clipboard isn't interoperable at all. No thanks. One clipboard. Consistency.

In reply to:

---

As far as draggin the item on to the dock. Sure, i can do that. I actually use the voice commands over the dock.

---

You referred to a quick way to email a file, I just told you one. It's completely independent of any other use of the Dock and has nothing to do with voice launching. Drag the file you want to email over to the dock, exposing it, then drop onto Mail's icon. Instantly a new email is created with that file as an attachment. Is that not what you were looking for?

In reply to:

---

I really dont want OS X windowfied, by that i mean all the crap that comes with windows as an os.

---

You mean like the interface and behavior?
If icon preview still isn't your piece of pie, how about using column view and looking in the information column? Or turning on the inspector (command-option-I) and simply clicking each file for which you want to see the preview (and make sure that the preview section is expanded)?

In reply to:

---

I think everyone keeps refering to the dashboard mostly is because its not what people have been asking for. Yet thats all apple seems to be proud of.

---

Some people are really excited about it and it's only your impression that Dashboard is all that Apple is proud of when it comes to Tiger. Look at Apple's Mac OS X page, it's not just Dashboard. Lots of people focus in on it because it's a bright shiny interface item.

In reply to:

---

Oh and spotlight, yay. I may be in the minority here, but i know where all my files are already.

---

Well, if you think Spotlight is only about finding files, then you missed the boat. It's an API that allows for extensible data searching. It can be anything. Emails, RSS news items, pictures, music (including ID3 tags), movies, chat conversations, web history, address book, calendar items, and on and on because it's extensible. The possibilities are endless. Then again, if you want to think of it just as file searching, well, then you're not taking advantage of your computer to the fullest.

In reply to:

---

Except for specific frames in a 1500 frame animation, for you smart ass's waiting to pounce on that point. Spotlight isn't going to tell me anything about frame composition.

---

Yet. Given appropriate metadata labeling, it could.

In reply to:

---

oh and it would be nice if the entire computer, hardware, OS, software was fully utilizing the 64 bit architecture it brags about. instead of a few parts and peices. I think apple is misleading when they describe their 64 bit architecture.

---

Take advantage of it how? I want specifics of how it won't be in Tiger.

In reply to:

---

My biggest beef I guess is the open gl thing.

---

Sure, more efficient subsystems are always a welcome change.

[d00d]

In reply to:

---

If anything, a case can be made to the contrary, that when menus are readily at hand in proximity to the app and window they govern -- and not, (as screens get larger and larger) at some distance away -- the user will have a much easier time of it.

---

What about the fact that tying the menu bar to the window causes dynamic placement? It's a matter of opinion of whether having a statically placed menu bar is more efficient, but I'd argue that Apple original interface elements placed it there. I'd be more concerned about the practical ramifications of trying to force the menu bar into specific windows at this stage and the assumptions made when designs relying on the globally placed menu were made.

[jmincey]

Guys, regarding the issue of "cut" and "copy" -- I see no valid argument whatsoever against the cut function (for moving files). I see only an argument against calling it "cut" and thus having a dual role for the cutting of TEXT versus the moving of files. I see Derik's point that this could cause some confusion, (notwithstanding that Windows has operated this way for years and years). Why not then simply have a command called "MOVE" which would in effect have the same function as the "cut" which we are now discussing?
If a user designates a file for moving, but is interrupted before specifying the destination to which the file would be moved, then the operation would not be completed and the file would stay in its original location. Or if in the middle of a move operation, the user changed his mind and wanted to move another file, it would abort the previous move operation in favor of the new one. And so it would go likewise in the event the user tried to move a file to a folder to which he did not have right/modify access.
If a user wanted to move several files from different locations ultimately into the same single destination directory, he should be able to hold down a modifier key in order to designate all the files to be moved (but without undoing any move command for the previous files. Then, after selecting the files to be moved, the user could select PASTE and all files would be copied to the new location (after which, transparently to the user, they would be deleted from the old location).
I have long wanted this functionality to be intrinsic to OS X. Moving files is not something so terribly exotic that it should require a user to seek out freeware or shareware solutions from third parties.

[d00d]

In reply to:

---

Why not then simply have a command called "MOVE" which would in effect have the same function as the "cut" which we are now discussing?

---

Then I'm satisfied. Nomenclature may seem like a minor thing, but when things are labeled poorly then issues (especially between platforms) will arise. The "replace" function is a good example.
Move may not be the best nomenclature either. I think some kind shelf function would work nicely (perhaps something tied to a corner of the screen that one could expand to see the contents of?), with the corresponding "shelve" command.

[d00d]

Actually, then again, I wouldn't use a shelf either because I just use spring loaded folders (which I personally find much more elegant, but that's me).

[jmincey]

I agree that nomenclature is important. Your shelf idea is interesting, and it brings to mind the idea of a "cart" into which files are placed and then moved to a new location. I think most users would understand the idea of this temporary "weigh station" in which files could reside, pending their movement to their new location. Librarians have carts which allow them to move their books and periodicals from one bookcase to another.
At the same time, though, I think the "move" terminology is pretty straightforward, and the only thing which might confuse the unwary user is the idea of a sort of "paste buffer" behind the scenes -- and your shelf or my cart would make this process more comfortable and understood.

[jesman0]

My vote is with the move command!
:P

[jmincey]

My vote is there too, though having said that, (and I'm sure Derik would be among the first to agree), on the eve of the Spotlight technology, the need for move is less compelling than ever before because the need for the careful manual location of files is itself less compelling.
Many files can carry multiple classifications and yet they can go only in a single folder. Of course, alternatively we can always litter our disk volumes with an alias for each possible way a file could be categorized into folders. Or, we could not worry about any of that and leave it to Spotlight to create instant, dynamic virtual folders based on our specifications.
Pretty nifty, eh?
Still, as impressive as Spotlight is, I lobby in favor of the move command. If we can copy files, delete files, rename files, etc., the OS should provide the means to move them as well. This hardly seems radical, and yet it has NEVER been a part of any Mac operating system. Amazing.

[MacCheetah3]

Hi
Originally posted by griffman

In reply to:

---

Windows: Include everything, make it hard to find and use and configure.
Mac: Include a solid set of basics, make it very simple to configure, and let add-ons do the customization work.

---

Precisely! Plus, add too much extra stuff (I prefer the term "crap" in the case of many M$ "features") and you get M$ IE on Windows. Unstable and vulnerable. Don't get me started on the "helpful" "features" of Windows /forums/ubbthreads/images/graemlins/grin.gif

[stroudtx]

It looks like it's just going to be a more mature and maybe stronger 64 bit support with some nice additions. If I can install 1 on all 3 macs, I'm in!

[Albertr]

What a bunch of ninis! Criticizing something they have never seen at all. Saying that your mother is underwhelming because we know what she produced is more to the point. Personally I am not saying that because I am too polite to say it out loud.
I for one I am waiting to be overwhelmed as I have always been by Apples achievements ever since the Apple II.

[jmincey]

"Personally I am not saying that because I am too polite to say it out loud."
I suppose this poster thinks he is being clever.
As I have said before, one can rightly speak about the known features and capabilities of a product even without test driving it directly. One cannot speak about how well these features and capabilities perform until having had direct experience with the product. THIS is the difference.
Think of cars for a moment. We can look at the published specs of new models and scan a list of all the features and options. And we can comment on these things even without having taken the car on a literal test drive. I don't need to experience going 0 to 60 in 3.5 seconds in order to know whether this capability is important to me or not. I don't need to experience a car's sun roof in order to know whether this feature adds value to me. And I don't need to drive a car in order to know what its fuel efficiency rating is. And so it goes with operating systems as well.
And I should think this commonplace distinction would be obvious enough to any thinking person.

[macnuke]

In reply to:

---

any thinking person

---

key words Jeff
key words

interestng and thought provoking thread tho...i've enjoyed. /forums/ubbthreads/images/graemlins/grin.gif

[BobofBobs]

How about: Cmd-C for copy, Cmd-Option-C for move (where the original item is not deleted until after it has been relocated), Cmd-shift-C for making an alias to a new location, and Cmd-Ctrl-C for Cut ( where the original item is deleted immediately). All this, and use Cmd-V to complete the end action. Or, you could have Cmd-C as the single cut, and variations of cmd-v for pasting. I also think tat with move, cut is unneccessary.