ResExcellence has a VERY cool guide to enabling multiple icon sizes in a single Finder window or on the Desktop - you can set the size on a PER ICON basis! Don't you just love Quartz?

http://www.resexcellence.com/hack_html_01/05-23-01.shtml

-Membranophonist

Not sure if anyone has posted this hack, but...

If you use custom Terminals for various tasks such as one terminal to telnet or ssh, and one terminal to tail a log file, etc. you can edit the .term file for each custom terminal to keep the shell you'd like to use -and- to also start up any default program or script you'd like.

If you'd like to set custom terminals with custom commands and still use your default shell, read the rest of this hint.

[Editor's note: This is similar to a tip that has been previously published, but it's a nicer wayto accomplish the same objective, so I've published it as a new hint]

I learned about this in college to make the title of xterms dynamic and found that the same method works with Terminal.app. I've created some aliases that allow me to have the title of the window reflect the machine that I'm on and current working directory of the shell, or of what file I'm editing. If you'd like a title on your terminal window that changes based on what you're doing, read the rest of this article...

In OS 9, you could single-click on a Finder window while an open/save dialog was onscreen, and the dialog would jump to that location. Very handy for fast navigation to often used folders (although I liked Default Folder even better!). In OS X, that same trick fails - a Finder click simply gets you the Finder.

Tonight, though, I found that you can drag and drop the location you are interested in from the Finder to the open/save dialog, and it accomplishes the same resut. If you drop a file, the filename is placed on the input line, and you can just hit return to open it; if you drop a folder, that folder is displayed in the dialog box. I'm not sure if this is common knowledge or not, but I had certainly no idea you could do this until I tried it!

It's not quite as simple as a click in the Finder, but it's close and quite useful!

If you have had sound problems (none, too loud, cutting out, etc.) after rebooting into OS 9 from OS X, you might try using a full shut down (instead of a restart) before loading OS 9. I have read on a couple of sites that this has solved sound problems for a number of people.

I can't verify this, as I haven't had any notable sound problems on my machine. If you have on yours, though, this may be worth a shot.

After some experimentation, and confirmation from another X user, I've discovered a bug in the way the Finder displays list views in a couple of situations. This has been replicated on a number of machines, so I tend to think it's a pervasive problem. I have submitted it to Apple's feedback site, but thought you might like to be aware of it as well.

The bug is related to a "name" column that continuously and automatically shrinks when in LIST VIEW mode. You can see the bug in one of these situations:

1. If you are viewing a folder that's at the root level of a hard drive (view the top level of your OS X disk in list view, for example). If you then click to sort by date, then click on any of the folders in the list (just once), then click to sort by name, the name field will shrink. From now on, any sort of click in the column names or in the finder list will result in the name field shrinking -- to the point where it vanishes! If you simply go one level deeper into your folder structure, this problem does NOT occur. Very odd, and very repeatable on two machines.
   
   
2. Take any folder, and put it on the desktop. You'll see the exact same behavior described above if you view it in list view.

I may not have explained this very well, but we've been able to duplicate the problem on two different machines, with those same two situations on each machine. So if it seems your list views are behaving a bit oddly, they may very well be. Hopefully this will be fixed in a future OS X update!

I don't know why but the tilde shortcut "~" to access my User Folder doesn't work for me (I get a "Permission Denied" alert). I've just discovered that "cd home" does exactly the same: it moves you to the user directory...I don't know if it's a common Unix feature or another alias made by Apple but it's neat!

descoff.

With OS X, Apple assigned command-N to "Make New Window" instaed of "Make New Folder", which was assigned to shift-command-N. To me, this makes sense, as I tend to open more new windows than I do creating new folders, so the easier key combo is the most used key combo.

However, some people tend to create a lot of folders on a daily basis, and the added keystroke could become quite annoying. For these users, here are two other means of creating new folders that may prove quicker than shift-command-N:

• Control-click (or right-click, if you can) in the Finder, and you get "New Folder" as a contextual menu item
  
• Place the "New Folder" widget on your toolbar, and you have one-click access from everywhere. To do this, select View -> Customize Toolbar menu in the Finder while the toolbar is visible (hit Command-B to show the toolbar)

So while one method is lost, at least there are some reasonable alternatives.

Robert Woodhead has written a very useful little utility called ShellShell, which basically wraps an Aqua GUI around the terminal. You launch ShellShell, and then pick any one of a number of 'macros', which will execute terminal commands in a GUI.

If that wasn't enough, one of the really neat features is that ShellShell will show you the command-line version of what you've asked it to do before it runs. So you can see how you would do the same thing in the terminal. For example, ps (Process Status) is a command-line version of Apple's ProcessViewer, and it has a large number of runtime options. When you first pick ps in ShellShell, you get a dialog box with about 15 choices in it, with two defaults (show all, and include processes without terminals (ie Aqua programs)) enabled. It shows you that the command line version of this command is ps -a -x. If you then add a check to "Display information about processes associated with user..." and enter your username, the shell command box changes to read ps -a -x -Uusername. This is a great way to learn the obscure command-line options that exist for many UNIX programs.

Once you've set the options you want, you click RUN, and ShellShell returns the results in another Aqua window.

If you're new to UNIX and the command line, ShellShell is a neat way to teach yourself about various options without trying to decode UNIX "man" pages or using the sometimes dangerous "try it and see what happens" method. Best of all, ShellShell is 'legoware'; if you like it, Robert asks you to send his children some Lego pieces (you'll have to see the details on the Read Me file).

ShellShell doesn't include every UNIX command, but it includes quite a few and is easily extensible. Hopefully authors will chip in with new "macros" for the program in the future.

Over the last few days, I've been trying to burn my first CD's with iTunes for X on my G4/733 with the Superdrive. On my first attempt, I accidentally left the screensaver and drive sleep enabled, and continued to browse web sites, download files, and play with mySQL while the disc burned. I wound up with a coaster, and wrote it off to my failure to set things up correctly.

On the second attempt, I remembered to turn everything off, and left iTunes in the foreground while it worked. When it was done, I stuck the disc in the PC (as it's the most finicky machine about reading homebrew CD's), and it didn't read. On the Mac, it read, but wouldn't play at all. Coaster #2, but this time, I didn't know why.

Before the third attempt, on a hunch I went into iTunes' prefs, and set the burn speed to 1x instead of 8x. I had already set the buffer to "large", so I left that alone. Again, I left iTunes in the foreground while it worked. The play list was about an hour long, and I left for about 45 minutes. I was surprised to find the disc done when I returned, so I can't really say it burned at 1x -- I need to do some further testing to see how fast it actually burns. When I tried this disc in the PC, it worked great ... it also works in all the players I've tried it in, so it appears I had a successful burn.

Pending further investigation, I plan on burning all my CD's in iTunes at 1x; it may be worthwhile (at least for those with G4/733 Superdrive machines) for others to do the same. Anyone else had similar or different experiences on similar or different hardware?