I can't remember seeing this before Mac OS X.4.3, so I think it's a new feature ... if you click on a document in the Finder, you can now choose Print from the file menu. You can also control-click on it, then choose Print from the contextual menu.
I have tested it out with a few document types. Images that open in Preview print, TextEdit documents print, but Pages documents do not.
[robg adds: I just noticed this myself, and in my testing, I found its operation to be so strange that I almost consider it a bug, not a feature! What happens seems to vary depending on the type of document you choose, as well as the state of the application which created the document.
For instance, if Pages is not running and I use File: Print on a Pages file, then that document opens in Pages, but does not print. If Pages is already running, however, the document opens and prints immediately (no OK button, it just goes).
With a Word document, if Word is not running, then Word launches and opens a new blank document, but not the one I told it to print. If Word is running, then the proper document opens and the Print dialog box appears. But this isn't common to all Office 2004 apps -- Excel documents will open and display the Print dialog, regardless of the state of the application.
PDF files printed from the Finder seem to work, but there's no print dialog; you tell the file to print, and then your default printer just starts churning out pages -- this is probably why Apple didn't map Command-P to the Print menu item. Overall, its behavior is somewhat strange...]
Here's a tip I was made aware of recently that I thought I'd share (though I'd like to take credit, I must give that to some Smart Friends of mine); it'll help speed up your Mac, and may reduce the appearance of the SPOD (the rainbow cursor). It's not a hack, and there are no modifications necessary to any of your software; there's nothing to download, and there's a fringe benefit (subjectively speaking, of course) of cleaning up your Desktop.
The tip: Reduce the number of icons on your Desktop!
That's it. Really. No, really, try it and see. If you only reduce it by a few, you probably won't notice much of a difference, but the more you remove, the snappier it will feel (dependent on your machine, of course).
Why? Well, every icon on your Desktop is a little window, and as such, has a corresponding backing store allocation in the window server. Lots of these little windows apparently can put a strain on the window server, especially when you've got lots of other (normal) windows open as well.
Don't believe me? Well, you can see for yourself, by running Quartz Debug found in /Developer -> Applications -> Performance Tools (assuming you have the Developer Tools installed -- you do have the Developer Tools installed, don't you?). Show the window list (Tools -> Show Window List), order by Application, and click on the various Finder entries to highlight each "window." You'll soon see that each desktop icon is treated as its very own window. See, I told you so.
No no, no applause necessary, cash donations will suffice...
[robg adds: I thought we had something similar in the archives, but I couldn't find it. Using Quartz Debug was somewhat enlightening for me; I don't have a ton of icons on my Desktop (about 10 or so), but each one clearly uses up a chunk of memory. I didn't notice any speed bump from reducing the number, given the small number I had to begin with. However, I suspect that if your desktop looks like the landing zone for 400 daily flights of icons and folders, then you would see a nice speed bump -- if you fall into this category, and try working with a clean desktop for a bit, please post your experiences.
For those who don't have Xcode (Developer Tools) installed yet, I wrote a very detailed how-to for Macworld a while back...]
When you duplicate an item (myfile.txt, for example) in the Finder, the duplicate's name becomes myfile copy.txt. If you're a Unix user, you might prefer to see the Unix-style copy syntax, which would be myfile~.txt.
To change the default copy name, navigate into /System -> Library -> CoreServices -> Finder.app -> [Control-click and Show Package Contents] -> Contents -> Resources -> English.lproj, and then open Localizable.strings with administrator privileges. Replace this line...
"N4" = "^0 copy";
...with this line:
"N4" = "^0~";
Save your changes, quit the editor, and relaunch the Finder (Option-click-hold on its Dock icon, via Terminal, Activity Monitor, etc.).
Another thing you should know is that known extensions will make the tilde appear before the dot, while unknown extensions will produce a name like User.ini~. Pure old-school!
[robg adds: As with any system file modification, I strongly suggest you back up this file before modifying it. This file contains all of the Finder's responses to various events; you could tweak the heck out of your system by changing multiple lines in this file -- from a quick look, I think you could, amongst other things, rename the Sidebar, change the way labeled items are displayed, tweak various Spotlight search language, modify error messages, and tons more. One line of interest to me is this one:
"N2" = "untitled folder";
Change the untitled folder bit to something else, and you change where new folders appear in a sorted-by-name view. In my case, I set it to _• new folder (the underscore is really a space; I just wanted it to show here), which forces all new folders to the top of my column view windows.
The easiest way to edit this file is to drag it to your Desktop; this will make a copy, leaving the original in place. Make another duplicate and add "backup" or somesuch to its name. Now open the Desktop copy of the original, and make your changes. Save the changes, and drag the modified file back into the English.lproj folder, and answer the authenticate and replace dialogs as necessary. Note that this will change the permissions on the source file, though I've never had any issues it. If you run Disk Utility's Repair Permissions, all will be back to normal...]
On an iMac G5, it's impossible to turn the screen off immediately. There is a workaround:
Create a screen-sized black image in your favorite image editor.
Import that image into iPhoto (like any picture).
Create a forlder named "Black" in iPhoto, and drag your picture into it.
Open System Preferences -> Desktop & Screen Saver, on the Screen Saver tab, scroll down to the iPhoto section and choose the "Black" folder.
Configure one Hot Corner to launch the screensaver.
That's it; now you just have to put your mouse in the corner of the screen to have a black screen.
[robg adds: Note that this isn't a screen saver as such, just a quick screen blacker. When I wanted something similar for my Apple LCD equipped Mac, I just created a shortcut (using Butler) to fast user switch to the login window...]
We all know that if you select an item in a Finder window (in column or list view) while holding down the Command key, you can select non-contiguous items in the column/list by clicking on them.
If you try to select contiguous items, though (by dragging through them), you end up dragging your previously selected items, unless you drag through the empty space to the right of the filenames. If you drag in the empty space with the Command key down, you can select contiguous items, and then command click to add/subract from the selection.
This is very handy for selecting groups of files that are scattered in a list/column view window.
I have noticed that rapidly triple-clicking a folder in Tiger opens your chosen folder's window, and then returns you to the orginal folder you first clicked on. This works even if the folder's window opens on top of the original folder you triple-clicked. In practice, it appears to work as an 'open window behind' command.
This only works if the window you open has a lot of icons or you are using a picture as the background pattern for that window, so I supect it is a bug of sorts to do with timing issues.
[robg adds: In experimenting with this, I was able to make it work with a variety of folders -- even those in column view with only a few items. Still, I agree with leeww in that it appears to be some sort of a timing glitch. Since I use OS X in single-window mode, I was using Command-triple-clicks, which also worked just fine. I also tested this in 10.3, and it works the same way there.]
If you have two folders that have certain files in common, and you want to delete all the items in the second folder that have the same name as an item in the first folder, here's how to do it:
Select All in the first folder.
Drag the selection onto the second folder.
Select 'Replace' and check 'Apply to All' in the resulting dialog.
Choose Edit: Undo Copy of nn Items from the Finder's menu.
This will undo the move of files from folder #1 to folder #2, but it will not undelete the matching items in folder #2 which were replaced by the copy. This is not unlike the "Difference" operation in set theory.
[robg adds: I'm not sure whether this is a bug or a feature, but it does work as described. I tested it in both 10.3 and 10.4.]
While I love working on a Mac, I really hate the fact that you don't have an option to remove Mac-specific files from the zip file created by Finder's Create Archive. I often find myself creating an archive on the Mac only to have to open it with WinZip on the PC so I can take out the hidden dot files (e.g .DS_Store).
So I hacked up this code for the small little archives I create for my website. The code isn't perfect, but I'm sure someone can clean it up and put in some better error trapping.
-- Script name: WinZipMe
-- zip command options: -r = recursive,
-- -j = junk path (similar to Create Archive)
tell application "Finder"
-- Note: There's no extensive error trapping on this script
-- (e.g. folder counts for larger folders to show warnings)
-- You could also take off any .xxx suffix before adding
-- the file to the .zip if needed
set theItem to selection as alias
set itemPath to quoted form of POSIX path of theItem
set fileName to name of theItem
set theFolder to POSIX path of (container of theItem as alias)
set zipFile to quoted form of (theFolder & fileName & ".zip")
do shell script "zip -r -j " & zipFile & " " & itemPath
-- delay 1 -- this may be needed (and adjusted) for larger folders?
try -- We don't need to say anything if there are no .DS_Store files
do shell script "zip -d " & zipFile & " '*.DS_Store'"
Wouldn't it be great if holding down the Option key while choosing Create Archive would exclude the special hidden Mac dot files?
[robg adds: If you're running 10.4, you can make this script a Finder plug-in using Automator; then it's just a control-click away with any file or folder selected. Open Automator, click on the Automator Library item, then drag the Run AppleScript action to the work area. Replace the (* Your script goes here *) line with the script above, and use File: Save as Plug-in to create a Finder plug-in (I called mine WinZipper). Select anything in the Finder, control-click, and then choose WinZipper from the Automator sub-menu.]
I found out something annoying about the hard drive icon on the desktop: if you have the Show Item Info option enabled (in View -> Show View Options), then the amount of free space in the info line never gets updated by itself. You either have to quit the Finder, reboot, or log off and on to make it refresh).
I read in some internet forum that copying any file to the top level of the drive (/) would make the available space figure refresh. So what I did was create an empty file in my Documents folder (touch space.txt in the Terminal), and then using crontab and a small script, copy this file every five minutes to /.
Here is the script, which I named freespace_updater.sh:
I know this is very dirty, but at least it refreshes my free space info every five minutes.
[robg adds: I tested this, and was surprised to find that it's true -- if you have hard drives visible on the desktop, and use the Show Item Info option, the free space value never seems to update. But copying and deleting a file from the root level forced an instant update. I would switch the order of commands in the script (cp first, then rm), since that way, nothing is left at the top level, and it seemed to work just as well when I was testing it. What didn't work, somewhat oddly, was touching a file at the top level; it seems an actual copy operation is required to force the update.
If you have multiple volumes, you'd probably need the script to copy a dummy file to the top level of each of them.]
I'm afraid to submit this hint for fear everyone in the world knows this except for me ... in 10.4, without X11.app launched and without any Terminal open, you can navigate in the Finder to, for example, /usr/X11R6/bin and double-click on a binary icon like xclock or xterm or xeye or xcalc etc., and it will simply launch -- cleanly, without starting a Terminal session or anything.
For years, I have either launched everything from the command line, or made application wrappers with Platypus or AppleScript, and I was stunned to see that 10.4 (which I have used since it became available) offers this feature. The only shortcoming is that it doesn't seem to permit drag and drop, but perhaps there is even a trick to getting that to work.
[robg adds: I also wasn't aware that X apps could be launched via a Finder double-click; I've been launching them from X11's Terminal every since I started playing around with X11...]