The following is more of an undocumented change than a hint.
In Finder's Column View (where I spend the vast majority of my time), if you use Select All (Command-A) with a folder is selected, previous releases of OS X would highlight the entire contents of the selected folder. In 10.6, I am seeing the behavior change to selecting the entire contents of the folder in which the selected folder resides.
This actually makes more sense because it is consistent with Select All used on a non-folder item, but it's going to take me a few days to re-calibrate my brain and fingers.
[robg adds: In testing this, I noticed that the behavior differs depending on how the folder is selected. If you select a folder with the mouse and then press Command-A, the behavior is the same as previous versions of OS X. But when you use the keyboard to select a folder, pressing Command-A highlights everything at the same level as the selected folder. I'm would think one behavior or the other is a bug; it seems they should be consistent.]
I was very disappointed that I couldn't add the Size column to the list view in search results in Snow Leopard like you could do in Tiger, since Apple gave us the impression that Spotlight would include additional ways to sort results in Snow Leopard. Only Date Created and Date Modified were added as options in 10.6; the others are grayed out.
Fortunately, I found a way to force the Size column to appear, as well as Comments, Version and Label columns. You'll have to edit the com.apple.finder.plist file found in ~/Library/Preferences, using the Property List Editor app (included with Xcode) or PlistEdit Pro.
Open the Root node, then navigate down into SearchViewSettings » ListViewSettings » columns. Then choose the column you want to activate in the column list (ie. Size), and set the visible key to yes. Save the .plist and relaunch the Finder (Option-Control-click on the Finder icon in the Dock).
Note: you must have done at least one search, and selected one of the additional columns in the View Options panel for the search results (Date Created, for example), or else your .plist file may not contain the SearchViewSettings node.
Warning: Apple probably disabled these columns for a good reason, as there may be some bugs that could cause problems on your system. I didn't have any problems with the size column, but be warned.
[robg adds: I have no idea why it's taken over three years (and counting) to fix something that worked in 10.4. Until Apple gets it fixed, though, this seems to do the trick. I tested it on my MacBook Pro, and haven't had any problems as of yet. Note that you won't be able to actively enable/disable the columns in the View Options dialog, but all the columns you set to yes will show in your search results -- and once they're showing, you can sort as expected by simply clicking a column heading.]
This has been mentioned before, but given that this just relieved the woe of a colleague who had upgraded to Snow Leopard, it is perhaps worth mentioning again:
If Finder seems to routinely "hang" or stop responding, deleting the Finder preferences file (com.apple.finder.plist) in ~/Library/Preferences, and subsequently restarting the Finder (using Terminal, Activity Monitor, etc.) may solve your problem.
Here's a workaround to making a Smart Folder stack. You can probably use Folder Actions to accomplish this in Snow Leopard, since Apple added the Date Created option to Spotlight search. I prefer to use Noodlesoft's Hazel, however.
Create a new directory and subdirectory for handling your Hazel-driven dock stacks. (~/SmarterFolders/New Applications). I made SmarterFolders to contain New Applications, the folder which will later be a stack of its own.
Create the first Hazel rule for the /Applications directory, and make it look like this. The Growl notification reads: File is new. An alias has been created in New Applications.
All Conditions met:
Date Added is Today
Comments do not contain NewApp
Do the following:
Make Alias in New Applications
Send Growl notification: file is new. An alias has been created in New Applications.
Add Comment "NewApp"
Create the second Hazel rule for the ~/SmarterFolders/New Applications directory, and make it look like this. The Growl notification reads: file is 2 weeks old. Alias has been moved to Trash.
Date Created is not in the last 1 Week
Do the Following:
Move file to Trash
Send Growl notification
Make sure you check Delete duplicates in the Hazel menu screen for the New Applications folder.
Drag New Applications to the Stacks area of the Dock. Change your settings as desired.
Clipping files in Snow Leopard have gained significant features. First, they now work with Quick Look. Second, you can open a clipping file and actually select a portion of the text to copy. Finally, they have a fully-functional title bar, so you can Command-click (or Control-click) the title to see the full path.
[robg adds: In 10.5, you actually could copy text from clippings, but the selected text didn't highlight, making it very hard to use this feature.]
As pointed out in this truly ancient hint, if you have multiple Finder windows open, Option-clicking the minimize (yellow) button will send all of those open windows to the Dock. No big deal hint there.
However, now with Snow Leopard, Option-clicking on any docked window will now release all docked Finder windows.
[robg adds: In 10.5, Option-clicking on one of many docked Finder windows didn't do anything, whereas it did work for docked windows from Firefox, TextEdit, and other apps.]
I noticed the Finder was consuming all of my memory and 40% of my CPU power. I found this reproducibly occurs if you leave a window open in /tmp, and have it set in Cover Flow view mode. When looking at /tmp, memory and CPU usage is higher than normal in other views as well, but Cover Flow really spikes it.
The CPU usage is not a bug, it's simply the Finder having to rapidly update the icons of the transient files flickering in and out of /tmp. As for the 3.5GB of memory usage, while this might indicate some sort of memory leak, I'd also guess it might instead be some sort of too-aggressive Finder caching that's unsuited for the transient directory behavior. (It takes a long time for the Finder to soak up all that memory, but the CPU effect is instant.)
So the hint is: don't view /tmp in Cover Flow view mode!
You can select a folder or iPhoto album in the Desktop subpane of the Desktop & Screen Saver System Preferences panel and tick the Random Order checkbox. This works fine until you logout / login or restart -- then the image defaults back to the Lightning picture until the next 'change picture' interval occurs.
For example, if you have Change Picture set to Every Day, on restart you won't see a picture from your chosen folder until up to 24 hours later. Meanwhile you're stuck with the default (IMHO, ugly!).
Solution? Go into the preferences pane, untick and retick the Random Order box, and your desktop is refreshed with a new random image. You can automate with a short applescript and add it to Accounts » Login Items:
tell application "System Events"
tell current desktop
set random order to false
set random order to true
This bug has persisted on several of my machines through 10.5.7.
[robg adds: I don't see this issue on my laptop, which is presently booting between two OSes regularly -- when restarting in 10.5.7, one of my random images comes up. However, if it's happening to you, this is a pretty simple workaround.]
In the Finder, there are numerous ways to duplicate a given file: either copy and paste the file to the same place, Option-drag the file to the same folder, or Control-click on the file select Duplicate from the contextual menu (or just press Command-D in the Finder).
Interestingly, the behavior of renaming the copied file for these three commands differs slightly. While duplicating or copying and pasting appends copy to the end of the filename (unless it already ends in copy, in which case it begins to enumerate) option-dragging the file to the same folder results in a slightly more useful naming system.
If the original file does not end in an integer, the new filename will be appended with the number 2 instead of copy. If the original ends in an integer, however, Finder does something quite useful -- instead of appending 2 to the end of the file, it recognizes the integer and adds one to the value.
For example, Report.doc will be renamed to Report 2.doc, but Report Number 67.doc will be conveniently renamed to Report Number 68.doc.
[robg adds: This is marked 10.5 only as I believe this behavior was new in OS X 10.5.]