This is no big deal, but you can use the Project Gallery as a standalone application. Instead of having Word, Entourage, Excel, and PowerPoint in your dock, you can just have the Project Gallery itself.
You'll find it in the Microsoft Office 2004 folder, then in the Office folder. It's called Project Gallery Launcher, and it even has the nice Office "O" as its icon. This can save dock space and let you have access to all the Office programs and use that nice O in your dock. This only works with Office 2004.
I hate reading a great story on Slashdot or some other news site only to see that it has already been Slashdotted. So, I have started to use Coral Cache. Since the more people that use the cache, the better it is, I wanted to make it as easy as possible. I looked for a Safari plugin to use it, but I didn't find one. So I decided to make a quick OnMyCommand command. The one down side of it is that with it not being a Safari plugin, it takes two steps to use: one to copy the URL and one to send the URL to Coral Cache. Since I have not done anything before with OnMyCommand, I don't know if it is possible to do it in one step with OMC recognizing it as a link.
In the old days of Mac OS X, it was possible to put an alias of your Volumes folder in the dock. You can still do that in Panther, but the aliases of the Volumes are no longer navigable, and it won't update when you add and remove CDs and drives. I know there are a lot of discussions about that, but none of the solutions (including shareware) are suitable for my needs. I have a lean system; not even the Finder is running as I use the Terminal instead. Via folders in the dock, I have quick access to all of my files, except to CDs, DMGs, Volumes, etc.
Finally I found a solution to have a folder in the dock which is both dynamically updated after mounting or ejecting a volume, and it's navigable. The solution is to use Folder Action Scripts. Read the rest for the how-to.
[robg adds: The screenshot at left (click it for the large version) is from my machine and demonstrates (a) how this works if you haven't seen it before, and (b) that this hint does work. Note that you can do something similar by just making aliases of your drives and tossing them in a folder. However, this more complex solution will dynamically update the folder's contents as you add and remove CD-ROMs and other volumes.]
This is probably a no-brainer for many people, but it never occurred to me until today. Every morning when I wake up, I check my e-mail, take a shower [editor: get dressed?], eat breakfast, brush my teeth, and finally, grab my iPod and take off for school. Of course, I can't just "grab" my iPod and go, because it's always mounted on the dock, so I have to find my iPod icon on the desktop, right-click, and select Eject (or, left click and command-E). This process can be mildly annoying, especially when I'm in a rush.
So today, I finally decided I should try to make it as simple as a keystroke. First, I created an AppleScript (my very first, no less):
tell application "Finder"
I saved it as an application (but I guess you can save it as a script) in ~/Documents -> scripts. Then, I went and downloaded Xkeys. After that, I installed Xkeys, assigned F13 to run the script application, and voila! F13 is now my own "eject iPod" key. I just wished I could assign F16 for the task, as the keyboard that came with my iMac G5 has F16.
You can go back through the searches you performed in any text field in the Finder's "Find" window (which you can bring up by typing Cmd-F) by selecting the text field and pressing Cmd-Z (Undo). Note that logging out, restarting changing the search parameters (date modified, kind, etc.) flushes this basic "search "history."
[robg adds: This works, but it's not as nice as a real search history -- there's no "redo," for instance, so once you've gone backwards, you can't go forwards. But it does work, and for more than one level, too.]
I've just discovered a potentially nasty behaviour of the Finder's Find dialog when used in "Specific Places" mode. I wanted to remove a specific place where I had been looking for something before. There are buttons for Add and Remove on the Find panel, but instead of using the Add button, I usually add folders to search with a drag and drop from Finder.
So, this time I just, instead of clicking and using the Remove button, I dragged the folder I no longer wanted to search and dropped it to the Trash. In this case, it was my user's Library folder. To my surprise, I didn't see usual "puff." To my horror, my entire Library folder was now in my Trash!! I managed to do Command-Z quickly, but still haven't logged out/in, and now my Safari doesn't make new tab on Command-T.
[robg adds: I tested this on a duplicated folder, and it's definitely a problem -- you're not really in trouble until you empty the trash, of course, but if you don't know about this behavior... This is a very bad design choice, in my opinion. I don't think an action in a Find dialog box should affect the 'real' instance of the folder. This is particularly true given Apple's use of the trash can in other aspects where it is "non-lethal" (dragging a disk image to the trash ejects it, but doesn't erase it from your hard drive). The moral of the story is: Use the Remove button in the Find dialog, at least until or unless Apple changes this behavior.]
A previous hint here explained how to use the "Go to folder" in Cocoa apps' Open and Save dialogs -- just hit / or Shift-Command-G and the box will appear. You can then enter a path, and use the Tab key to auto-complete fields.
But what if it auto-completes to something you didn't want? For instance, you type ~/D and hit tab. The box completes to "~/Desktop." But maybe you didn't want to go to ~/Desktop, so pressing Tab was not a good thing. Instead of pressing Tab, you could have used Option-Escape two times. The first time you press it, the path will expand to ~/Desktop. But the second time you press it, the path will expand to ~/Documents. So using Option-Escape might be preferable to Tab when you have multiple directories that start with the same letter; you can then just cycle thru them and pick the one you want.
I must begin by giving the proper credit where it is due: I found this hint by way of GUI gurus demograph68 and Dave-o from the MacNN forums. Now then, if you're tired of having a plain white sidebar in your Finder windows, you can change the color to any you wish.
Note: This procedure involves modifying files crucial to the OS and, if done incorrectly, can basically hose your Finder!. So, back up the files to be changed before you change them. Also note that this procedure works only for 10.3.5, and may break with future system updates. Read the rest of the hint for the detailed how-to...
[robg adds: I tested this one, and it indeed works, as you can see in the image at left (now I just need to go pick a color I really want to use!). So any hotshot Cocoa authors out there want to create a GUI for this hack? Not knowing the first thing about Cocoa, I have no idea if it's even possible to modify the Finder on the fly, nor if it's "safe" to do so ... but it'd be a cool hack!]
It's just a little thing, but it bothers me that when sorted by Kind in List view, folders are clumped under "F in the middle of the file list. Sure, I understand that the computer sees a folder as just another file, but to my mind, a folder is a container for files, and as such, is distinct from other file types (at least in the context of situations in which I want to sort by Kind in the first place). For this reason, I would prefer folders to sort either to the beginning or the end of a list sorted by Kind.
For most applications, the string used to define the "Kind" of documents it "owns" is stored in that application's Info.plist. However, in the case of the system, the location is a little harder to find. It turns out that it is in the Localized.strings file of a given language's .lproj folder, within the directory: /System -> Library -> Frameworks -> ApplicationServices.framework -> Versions -> A -> Frameworks -> LaunchServices.framework -> Versions -> A -> Resources. Within the Localized.strings file, the addition of a single space eliminated my sorting order woes, ie. changing:
"Folder" = "Folder"; to "Folder" = " Folder";
A full restart was required for the changes to take effect. Other types included in the file are: "Alias," "Application," "Classic Application," "Document," "Package," "Trash," "Unix Executable File," "Volume," and "%@ Document" which seems to refer to files "owned" by Classic apps.
Other than breaking AppleScripts that are dependent on "Kind ... is folder" statements, I haven't noticed any ill effects (so far...). Since this hint only edits the localized version of the string, my (unqualified) opinion is that it should be safe. Any reasonable application should be aware that OS X can be running in a number of languages, so it shouldn't be dependent on the localized name of a file type, but rather the "archetype" name -- i.e. the string on the left side of the equation. For example, the Finder's "Find..." command still works. However, since a system file is involved, proceed at your own risk. Make a backup first, be careful making changes, and for security reasons, make sure the ownership and permissions haven't been altered. Also keep in mind that the changes may be wiped out by future system updates.
[robg adds: This change worked as described. To edit the file, you'll need to have admin powers. I changed the ownership on the enclosing Resources folder to my admin user, edited the file with TextEdit, told it to Overwrite when saving, and then switched the ownership of Resources back to the system. After a restart, folders did indeed float right to the top of the list. If you want them to go to the end of the list, you'd have to use one of the characters discussed in this hint.]
This is a pretty minor hint, but it saves a lot of frustration for people like me who still can't keep the crayon between the lines. It used to be that whenever I was trying to select an item in a submenu (like "Recent Files" menus) and the menu was extra wide because one of the items in it had a really long name, I would move the mouse too far up or down, and the submenu would disappear before I got over to it.
The solution is very simple. Single click on the menu you want (don't hold down the mouse button after you have selected it). This will open the menu, and leave it displayed. Now move to the menu item containing the desired submenu. Here's the tricky bit -- hold down the mouse button while you move to the submenu. This will keep the selected menu item active until you reach its submenu.