Apple Seeds Mac OS X Leopard (9A527/9A528a)

[Eric5h5]

one feature they need to bring, is user customizable interface, arnt macs all about creativity? STOP STIFLING ME!

Yeah, I think you're supposed to focus on creating actual stuff, and not fiddling about with the OS. (This reply is actually somewhat serious...I used to do that sort of thing, but now I don't even have a custom desktop background. Total waste of time...far more interesting things to be doing....)

--Eric

 

[weckart]

i got it to download but no matter what file extension i give it, it tells me it is not a movie file, and when it opens flash nothing happens, it is just a white screen.
So is there any other way to get it?

For future reference, for flv files, you can try the following:

1. Run under VLC
2. Convert using iSquint (or VisualHub for more formats)
3. Add the Perian package to Quicktime to run flv under QT.

 

[noaccess]

I'll go ahead and make this easier for you. Leopard Video [40MB]

Heey... this is the original!
Thank you.

 

[aLoC]

If you have the dock locked in the "show position" all the time, ie no hiding, and you resize a window and get it down to the dock, it stops sizing. Think of it as hitting a brick wall, you can go sideways but not down anymore. The window just grazes the top of the dock.

I know but I'm suggesting it would be better if the window pushed the Dock down. Because the user is indicating that they want to use that part of the screen for their window right now.

 

[mrparet]

There's a little easter-egg in this video! I think... To me, it looks like there is an Apple shaped purple "cloud" thing apple. This is seen most clearly at 0:26. What do you think?

 

[dlpmaster]

Is the video supposed to not have Audio?
I have just about every codec and I get no Audio still, does anyone have this issue?

 

[crjeong]

Is the video supposed to not have Audio?
I have just about every codec and I get no Audio still, does anyone have this issue?

It has no audio.

 

[Simmerl]

Can someone please confirm on whether or not cut is still broken in the Finder? Also, have they done anything about the green button to indicate state (zoomed vs normal)? Or maybe a quick way to maximize? For example, Alt + clicking the green button could be maximize. (...)

What you're basically saying is you're angry OS X doesn't behave like Windows.

Cut isn't "broken" - you just don't use it for moving files. Drag and drop them instead.
The zoom button, it does behave irregularly, but there's no need to make it behave like a Windows maximize button.

Just my 2c. ^^

 

[aLoC]

one feature they need to bring, is user customizable interface, arnt macs all about creativity? STOP STIFLING ME!

One advantage of not having themes is that you can sit down at any Mac anywhere and instantly recognize the GUI and start using it.

 

[motulist]

For future reference, for flv files, you can try the following:

1. Run under VLC
2. Convert using iSquint (or VisualHub for more formats)
3. Add the Perian package to Quicktime to run flv under QT.

4. Open a new safari window and drag and drop the .flv file onto it.

 

[exigentsky]

What you're basically saying is you're angry OS X doesn't behave like Windows.

Cut isn't "broken" - you just don't use it for moving files. Drag and drop them instead.
The zoom button, it does behave irregularly, but there's no need to make it behave like a Windows maximize button.

Just my 2c. ^^

I didn't want to get involved again, but you are clearly misinterpreting me. My main complaint about the zoom button is that it doesn't indicate state. It always shows a + regardless of whether or not the window is already zoomed. I did not advocate making the it behave like maximize. I mentioned a compromise so that would allow easy access to both zoom and maximize. Pressing Alt or Ctrl and clicking on it could make it behave like the familiar maximize. While you may not like maximize, many others find it useful (especially on a Macbook with a 13.3 in screen).

As for Cut, I'm sorry but IT IS BROKEN. I filed a bug report with Apple and they even said they're working on it. It's an actual option in the Finder, but it doesn't work. Try this on Tiger, select a file or folder and now go to Edit, you will see that the second option is grayed out and reads "Cut Command icon - X." However, the feature itself and the keyboard shortcut do not do anything. Cut is an essential feature and dragging and dropping is not the answer. One does not replace the other. Cut is a lot faster and gives free navigation without having to rely on spring loaded folders. I like OS X, but I will not ignore its flaws and Apple needs to fix Cut. When I review Leopard I will definitely mention this if it is still in this state. It doesn't take 6 releases to implement a feature that we've relied on for close to a decade.

 

[sammich]

I know but I'm suggesting it would be better if the window pushed the Dock down. Because the user is indicating that they want to use that part of the screen for their window right now.

Not blaspheming here or anything, but think of the dock at the windows task bar. When either of them is set to 'hiding off' it's always on top of every open window, it's the whole idea. If you can push it away off the screen, what the point of having it 'always showing'?

 

[sammich]

I'll go ahead and make this easier for you. Leopard Video [40MB]

Absolutely amazing. I don't think I'll ever get past that stage of the installation

 

[rockstarjoe]

I didn't want to get involved again, but you are clearly misinterpreting me. My main complaint about the zoom button is that it doesn't indicate state. It always shows a + regardless of whether or not the window is already zoomed. I did not advocate making the it behave like maximize. I mentioned a compromise so that would allow easy access to both zoom and maximize. Pressing Alt or Ctrl and clicking on it could make it behave like the familiar maximize. While you may not like maximize, many others find it useful (especially on a Macbook with a 13.3 in screen).

As for Cut, I'm sorry but IT IS BROKEN. I filed a bug report with Apple and they even said they're working on it. It's an actual option in the Finder, but it doesn't work. Try this on Tiger, select a file or folder and now go to Edit, you will see that the second option is grayed out and reads "Cut Command icon - X." However, the feature itself and the keyboard shortcut do not do anything. Cut is an essential feature and dragging and dropping is not the answer. One does not replace the other. Cut is a lot faster and gives free navigation without having to rely on spring loaded folders. I like OS X, but I will not ignore its flaws and Apple needs to fix Cut. When I review Leopard I will definitely mention this if it is still in this state. It doesn't take 6 releases to implement a feature that we've relied on for close to a decade.

The "Cut" in the menu refers to cutting the file name. Try it when editing a file name. Silly, I know, but that is the way they meant it to be I think.

 

[MacFly123]

Yup

Good to know Leopard is on the way.

Speaking of the desktop picture. The grass thing was way better than the purple black space thing. This one is atrocious.

I agree... Well.. I think it is a cool picture in and of itself, BUT NOT for a desktop. I have it on mine right now and it is very bright and distracting to me.... Not to mention that with Time Machine and the new Movie which is cool, but come on, can't you hear all the jokes right now??? Apple Sci-fi star trek nerd alerts bla bla bla..... You watch, it will happen!

 

[exigentsky]

The "Cut" in the menu refers to cutting the file name. Try it when editing a file name. Silly, I know, but that is the way they meant it to be I think.

It's true that it works like that. I can also cut a portion of your quote and paste it somewhere else. This is true for Cut in any OS. Cut takes text, pictures, graphs, etc. and allows you to paste wherever you want while deleting the original in the process. Apple knows that Cut is very useful for a wide range of tasks and they've implemented it for virtually everything else but when it comes to cutting files or folders. This is why it's broken. It is inconsistent for it suddenly not work for files and folders and is an essential aspect of a full Cut implementation. I again should add that Apple did not mark my bug report as "Behaves Correctly" or anything like that, they marked it as a duplicate of the original, bug 2717012.

They know the issue, but they just haven't fixed it yet. Frankly, that is appalling to me. They implement a lot of advanced cool features like Automator, Spotlight, Resolution Independence, Expose, etc. and then they forget about the basics. Why? I think it's because Apple thinks such a fix wouldn't sell many copies of OS X. "Oh yeah, and get this, we now have a complete Cut implementation! Pretty cool, huh?" It doesn't really make most people want to run out and buy it. For me, after seeing so many new features in Leopard, I have to wonder if Apple still has time to do the proper bug fixing and stability improvements. I would just want them to spend one release refining the basics because that's what I use 90% of the time. I don't need any new features. Just polish the basics, fix bugs, improve performance and make it even more stable. Of course, I'm in a minority, but that's how I feel sometimes.

Sorry for the length and ranting.

 

[curmi]

IAs for Cut, I'm sorry but IT IS BROKEN. I filed a bug report with Apple and they even said they're working on it. It's an actual option in the Finder, but it doesn't work. Try this on Tiger, select a file or folder and now go to Edit, you will see that the second option is grayed out and reads "Cut Command icon - X." However, the feature itself and the keyboard shortcut do not do anything. Cut is an essential feature and dragging and dropping is not the answer. One does not replace the other. Cut is a lot faster and gives free navigation without having to rely on spring loaded folders. I like OS X, but I will not ignore its flaws and Apple needs to fix Cut. When I review Leopard I will definitely mention this if it is still in this state. It doesn't take 6 releases to implement a feature that we've relied on for close to a decade.

There are some issues here surrounding consistency and potential for deletion in implementing cut. See here for some discussions on the matter.

 

[exigentsky]

There are some issues here surrounding consistency and potential for deletion in implementing cut. See here for some discussions on the matter.

Yes, exactly, if it were consistent, Cut & Paste would work for files and folders as well. There is no need for me to use a slower alternative when no new paradigm is created and a feature that should work is simply incomplete. I can understand for example that the zoom button doesn't maximize by default. It's a different paradigm and it has a different function with its own pros and cons. However, if it were supposed to maximize and you tell me to resize manually because it only takes another 10 seconds, that is just not going to do it.

It's true that there is potential for deletion/corruption, but if the code is good and well-tested it's a non-issue. I could list thousands of daily operations that have the potential for deletion or corruption, but I doubt you would do away with all such features. A complete Cut & Paste is not rocket science. It's fairly basic and has been implemented on every other modern OS without issues. I'm sure that the risks have been weighed and ways have been found to make them close to nonexistent.

I hope I've explained my position on this issue quite clearly.

 

[curmi]

Yes, exactly, if it were consistent, Cut would work for files and folders as well. There is no need for me to use a slower alternative when no new paradigm is created and a feature that should work is simply present. I can understand for example that the zoom button doesn't maximize by default. It's a different paradigm. However, when if it were supposed to maximize and you tell me to resize manually because it only takes another 10 seconds, I'm sorry but that is just not going to do it.

It's true that there is potential for deletion, but if the code is good and well-tested it's a non-issue. I could list thousands of operations that have the potential for deletion or corruption, but I doubt you would do away with all such features because of it. This feature is not rocket science, it's fairly basic and has been implemented on every other modern OS without issues. I'm sure that the risks have been weighed and ways have been found to make them close to nonexistent.

I think I've explained my position on this issue quite clearly.

Hey, breathe.

Don't get mad. I'm not saying I don't agree with you, I'm just saying that there are some issues.

On Windows, if you cut a file, it greys out. If you then cut another file, the first file goes back to normal.

Some would argue (and have) that this is inconsistent, as if you cut text, then cut some more text, the first bit of text has been deleted. Forever.

So, for consistency, this is what should happen with a file you cut. Of course, then it is easy to delete a file - which is why Microsoft didn't do it this way.

I would prefer it was consistent and deleted the file. It should pop it in the trash for you when you cut. But I would think Windows users won't like that behaviour. So once again, we'll have some inconsistency if Apple do it the Microsoft way.

And if we do it the "pop in the bin" way, you have the issue that if it is a very big file, you are really just doing a copy (of a big file) and then a paste (of that big file) - which you may not have room for on your hard drive. There will be two copies of the file as a result - one in the trash, and the one you pasted.

And then you think - hold on, what people really want is a "move" not a "cut". They want to move the file - select it for moving, then select where to move it to. So maybe "cut" is being overloaded here - and it really needs another shortcut for moving the file...

So, I'd just stress, there are some issues here. And don't get mad with me for raising them.

 

[exigentsky]

Hey, breathe.

Don't get mad. I'm not saying I don't agree with you, I'm just saying that there are some issues.

On Windows, if you cut a file, it greys out. If you then cut another file, the first file goes back to normal.

Some would argue (and have) that this is inconsistent, as if you cut text, then cut some more text, the first bit of text has been deleted. Forever.

So, for consistency, this is what should happen with a file you cut. Of course, then it is easy to delete a file - which is why Microsoft didn't do it this way.

I would prefer it was consistent and deleted the file. It should pop it in the trash for you when you cut. But I would think Windows users won't like that behaviour. So once again, we'll have some inconsistency if Apple do it the Microsoft way.

And if we do it the "pop in the bin" way, you have the issue that if it is a very big file, you are really just doing a copy (of a big file) and then a paste (of that big file) - which you may not have room for on your hard drive. There will be two copies of the file as a result - one in the trash, and the one you pasted.

And then you think - hold on, what people really want is a "move" not a "cut". They want to move the file - select it for moving, then select where to move it to. So maybe "cut" is being overloaded here - and it really needs another shortcut for moving the file...

So, I'd just stress, there are some issues here. And don't get mad with me for raising them.

I did breathe and then I edited my post. I just felt that some were trying to tell me that it doesn't matter or that I should use something else or even that it's not broken in a way. I don't think minimizing this issue is the right approach because even if some here don't care for it, many people depend on this feature. And everyone I know who switched from Windows got annoyed by this. Does Apple want to make their experience more difficult?

I think you're overestimating the complexities of a proper Cut implementation. It's just like in kindergarten where you cut a piece of cardboard paper and glue it somewhere else. I think a slight improvement over the Windows/Linux/Solaris etc. way is all that's needed. The flair for moving it to the trash and then taking it out again when pasted seems needless. When one selects Cut it is clearly deliberate anyway so all these safeguards seem superfluous for a feature that even Mac users are familiar with in different contexts.

 

[motulist]

As for Cut, I'm sorry but IT IS BROKEN.

It's not broken. The "cut" command has been a menu item in the Mac Finder for a few decades, but it has always worked the way that it does. It would be child's play to implement the cut-file feature if Apple wanted to, but they obviously don't want cut to work that way. In fact I'd bet that at some point Apple had implemented (or seriously considered implementing) the cut-file feature in a pre-release OS as a test to see if they wanted to use it.

Just because a feature is greyed out does not mean it is broken, it's there because menu items in menus (on the Mac) are designed to never change presence or location because it makes navigating infinitely easier than if items were appearing and disappearing based on context. So items just become greyed out when they are not applicable to the currently selected item.

Having said all that, I actually would like to see the cut-file feature implemented in the Finder. But over the past many decades Apple has clearly decided not to make it part of the Finder, so neither of us should hold our breath waiting for it.

If you really want it then I'm sure there's a shareware utility that'll add the cut-file feature to the OS.

 

[08380728]

As for Cut, I'm sorry but IT IS BROKEN. I filed a bug report with Apple and they even said they're working on it. It's an actual option in the Finder, but it doesn't work. Try this on Tiger, select a file or folder and now go to Edit, you will see that the second option is grayed out and reads "Cut Command icon - X." However, the feature itself and the keyboard shortcut do not do anything. Cut is an essential feature and dragging and dropping is not the answer. One does not replace the other. Cut is a lot faster and gives free navigation without having to rely on spring loaded folders. I like OS X, but I will not ignore its flaws and Apple needs to fix Cut. When I review Leopard I will definitely mention this if it is still in this state. It doesn't take 6 releases to implement a feature that we've relied on for close to a decade.

The problem you and other Windows users suffer from is due to M$ and silly and downright dumb fsckin implementations copied from other systems. The Pasteboard aka cut/copy/paste is intended for selected data to be placed temporarily in RAM to be migrated to another document either the same application or inter-applicationt!! Moving data in the above manner has been used by Unix systems years before M$ was even born "stdin/stdout". The primary use was and still is for ASCII data or Rich Text Format. As such it would be completely thickheaded to use the command to copy a 4 gig video file to move it to a different location on a hard disk. You will not have enough memory to accommodate such a task. Moving or copying files themselves execute Disk I/O tasks. The Finder of course offers Cut/Copy/Paste as it is intended, to be used with the text of file/directory names not the files or directories themselves.

Im sorry but what you are used to on an M$ system is another example of that companies failure to understand the logic behind such simplistic com-putative tasks which have been standardized decades before Microsoft decided to "Think with drunkenness" for the sake of not being scored for directly copying other systems. Kind of like a white cursor I suppose, all pages an documents after all are also white....so they decided to camouflage the cursor?? DUMB!!!

Your silly reasoning has no merit, in the sense that you still have to navigate the FS to paste the file in the location you wish, this is no different than using pop open windows to navigate to the directory to place the file. Either way you still need your mouse to navigate the FS. Here is another tip or 2, if you drag a file an navigate you system using pop open windows you hold down the Command key whilst dragging to move the file, Option key to copy, if you change you mind an want to cancel the operation simply drag it to the menu bar an let go of the file , as i say this will terminate the drag an leave the system as it was. If you still refuse to accept these methods, buy Path Finder, an replace the Finder with it an use the "Drop Stack" in Path Finder. This allows you to drag and drop a file or files eg 2 files then drop another 4 then another 3 then a single one on the Stack, as a temp holding location, then navigate your FS to the directory you wish to place the files then you may select any of the files you previously dropped in the stack, (single files, or the multi groups of files as described) and then move them using simple drag of holding option key down to Copy to the location.) NeXTSTEP had a similar feature called a shelf which was brilliant.

In summary, M$'s feature is fundamentally flawed, there are better ways an better alternatives. Do yourself a favor and investigate these possibilities and learn to adapt.

 

[exigentsky]

The problem you and other Windows users suffer from is due to M$ and silly and downright dumb fsckin implementations copied from other systems. The Pasteboard aka cut/copy/paste is intended for selected data to be placed temporarily in RAM to be migrated to another document either the same application or inter-applicationt!! Moving data in the above manner has been used by Unix systems years before M$ was even born "stdin/stdout". The primary use was and still is for ASCII data or Rich Text Format. As such it would be completely thickheaded to use the command to copy a 4 gig video file to move it to a different location on a hard disk. You will not have enough memory to accommodate such a task. Moving or copying files themselves execute Disk I/O tasks. The Finder of course offers Cut/Copy/Paste as it is intended, to be used with the text of file/directory names not the files or directories themselves.

Im sorry but what you are used to on an M$ system is another example of that companies failure to understand the logic behind such simplistic com-putative tasks which have been standardized decades before Microsoft decided to "Think with drunkenness" for the sake of not being scored for directly copying other systems. Kind of like a white cursor I suppose, all pages an documents after all are also white....so they decided to camouflage the cursor?? DUMB!!!

Your silly reasoning has no merit, in the sense that you still have to navigate the FS to paste the file in the location you wish, this is no different than using pop open windows to navigate to the directory to place the file. Either way you still need your mouse to navigate the FS. Here is another tip or 2, if you drag a file an navigate you system using pop open windows you hold down the Command key whilst dragging to move the file, Option key to copy, if you change you mind an want to cancel the operation simply drag it to the menu bar an let go of the file , as i say this will terminate the drag an leave the system as it was. If you still refuse to accept these methods, buy Path Finder, an replace the Finder with it an use the "Drop Stack" in Path Finder. This allows you to drag and drop a file or files eg 2 files then drop another 4 then another 3 then a single one on the Stack, as a temp holding location, then navigate your FS to the directory you wish to place the files then you may select any of the files you previously dropped in the stack, (single files, or the multi groups of files as described) and then move them using simple drag of holding option key down to Copy to the location.) NeXTSTEP had a similar feature called a shelf which was brilliant.

In summary, M$'s feature is fundamentally flawed, there are better ways an better alternatives. Do yourself a favor and investigate these possibilities and learn to adapt.

Spelling MS with a $ definitely makes you look objective. Your post highlights exactly what I feared. Blind arrogance and support for Apple's way of doing things while not considering that maybe this is a feature that many need and that just maybe Apple is in the wrong here. I suppose that because MS and others already have this, it is is hard to accept it as progress for OS X.

I'm not asking for a new feature, only for a more complete and consistent implementation of an existing feature. An implementation that works well on the several dozen operating systems I've used (BeOS, Windows: 95, ME, 2000, XP, Vista, Linux: SUSE, Ubuntu, Redhat, Fedora, Mandrake, Mandriva, Knoppix, Xandros, Linspire, Yopper, Kubuntu, Debian, Gentoo, UNIX: FreeBSD, PC-BSD, Solaris, etc.). I'm not the confused MS user you mistake me for. I'm sorry you consider that my "silly reasoning has no merit," but maybe you should try to view this from the perspective of the 95% not using OS X. Or even better, from an objective perspective. You think I "refuse to accept these methods," but you are wrong. I know the alternatives very well and I find them insufficient and slow for the way I work. This is very different. Once again, I only want a complete implementation of an existing feature and I'm far from being the only one. Like I mentioned, my bug report was not marked as "Behaves Correctly," it was marked as a duplicate. Thus, Apple does not pretend that this is simply the intended behavior.

I should also add that your technical information is completely inaccurate. Modern cut implementations do not copy a huge file in ram or even write it to a temp file to move it. They simply tag the file, for example on Windows it is visually represented as being grayed out, and then when pasted it is moved to its new location. It is no more expensive than drag and drop. The OS can't even distinguish the two at the IO level.

Next time you reply to me, please do your research. Carefully read my previous posts and you'll find most of your points answered. I'm not going to repeat myself again.

 

[The General]

Umm ... okay, wow ... I hate to say this but Leopard really is copying Vista in some ways. Here's one of them:

Click to see full sized image:

Look at the menubar. It's transparent, and the background is blurred. What the hell, man? The blur in Vista is awful, that doesn't mean it will be okay in Leopard!

 

[motulist]

The Pasteboard aka cut/copy/paste is intended for selected data to be placed temporarily in RAM to be migrated to another document either the same application or inter-applicationt!! ... it would be completely thickheaded to use the command to copy a 4 gig video file to move it to a different location on a hard disk. You will not have enough memory to accommodate such a task. Moving or copying files themselves execute Disk I/O tasks. The Finder of course offers Cut/Copy/Paste as it is intended, to be used with the text of file/directory names not the files or directories themselves.

Sorry to break it to you man, but you're completely wrong and all your reasoning is false - because the Finder already DOES allow you to do all the things you said it couldn't and shouldn't, like move a 4 gig video file via the clipboard system. But it only allows you to COPY and paste a finder file to a new location, it just doesn't let you cut it. It's simply a user interface problem that Apple doesn't want to confuse users with.