OS X 10.5.2 introduced a bug that affects several applications that use floating windows (tool palettes, inspectors, etc.,) and pop-out sheet dialogs, including InqScribe and older versions of RealBasic.
Basically, sheet dialogs won't function if you have a floating window open. Close the floating window(s), and the sheet dialog works again. It would appear that the floating window(s) steal the mouse clicks from the sheet dialog. Here's hoping it's fixed in 10.5.3...
I wanted to use Webmin to manage my DNS server on OS X 10.5 Server, instead of Apple's Server Admin, because Webmin has a better interface. One problem I had was how to get bind to start when the server was booted. After a few days of searching, I finally figured out how to do it. Disclaimer: This is not for the faint of heart and you could hose up your server if you are not familiar with the command line.
You need to edit org.isc.named.plist, found in /System/Library/LaunchDaemons/. What I changed was the Disabled key, which I made false instead of true. I also edited the ProgramArguements, where I changed the -f string to a -c, and I added an additional string, /etc/named.conf. Now when I reboot, bind starts up.
When installing the the recent Safari 3.1 update, I had a 'heart-in-the-mouth' moment. I was viewing one of my other Macs using Leopard's Screen Sharing. With the remote Mac ready to install the update, I allowed Software Update to start the reboot process. By now, we've all seen how Leopard handles updates which install during a reboot: after the user has logged out, but before the reboot, the update installation is performed with a dialog showing the progress.
However, what I found out by accident when sharing the remote Mac's screen during this process was that the update pre-reboot progress dialog responds to the Command-Q key combination. In trying to close the Screen Sharing window, I accidentally sent my Command-Q to the update progress dialog, causing it to quit in mid-update. Installation of the Safari update was cut short and I was returned back to the login screen instead of seeing the Mac reboot.
Logging in (and even rebooting) confirmed that the update installation had been stopped early. In the case of the Safari update, many apps would crash on startup, with WebKit 'unresolved' errors showing in Console. In this instance, the system was still usable enough to copy across the Safari update package and reinstall it manually to fix things. However, hitting this problem during deeper updates -- such as a 10.5.x release -- could leave an unbootable system.
The upshot is, when the pre-reboot update progress window is showing, keep your fingers away from the Command and Q keys, and be particularly careful when performing the update within a Screen Sharing session.
[robg adds: I haven't tested this one, but if true, I hope that a future Apple update will block the use of Command-Q at this stage of an update (or at least provide a confirmation dialog and a safe recovery after a reboot).]
I wrote a plug-in for the Mac OS X 10.5 Dictionary that provides the complete German-English dictionary from the well-known dict.cc site for offline use. You can read more about the plug-in -- and download it -- in this blog entry on my site.
To use the plug-in, run the installer package, then launch Dictionary and open its preferences. Check the box for the dict.cc dictionary, and you're good to go.
Leopard has problems with rules in Mail.app that call AppleScripts that, in turn, generate a new Mail message. The scripts won't run from the rule, even though they work fine in Script Editor. Here's a workaround...
Have your rule in Mail run an AppleScript that calls a shell script, like this:
do shell script "/Users/murphymac/shell_script.sh"
Then have that shell script run the main AppleScript. Here's an example of what the shell script (shell_script.sh in this case) might look like:
Design the main AppleScript so it targets certain messages, like a Mail rule would. Here's a simple example for selecting messages based on subject:
tell application "Mail"
tell (first message of inbox whose subject is "macosxhints") ¬
to if exists then
-- insert actions to be taken here
As an alternative to scripts that are triggered by a Mail rule, you can run an AppleScript on a schedule. The script can check the inbox for messages with certain subjects, dates, flag status, etc. If they find a match, they can perform the required task. See the link above for examples. This approach essentially mimics the role of Mail rules.
Some more quick tips for Japanese input methods with OS X. This works for 10.4, 10.5. Probably works for 10.3 as well, but I haven't verified this. Note that in OS X 10.5, there is a fair amount of (Japanese) Koeteri input method help in English accessible by choosing 'Koeteri Help' in the Input menu. In previous systems (10.4 and older), this help was only available in Japanese. Now for the tips...
If you type something in Japanese using Romaji input (big 'A' selected in the input menu droplet) and while the input still has a dark black underline (i.e. turn on Romaji input: Command-Space (must be changed from Spotlight's default)), you can switch modes between katakana, hiragana, expanded roman characters, and roman characters by holding down Option-Tab. Thus, typing in a phrase while in Japanese mode, the katakana version of the English word 'support' (i.e. Apple Support -- sapo-to), you can change modes as long as the text is underlined:
There is a fairly significant bug when using FileVault in Leopard that as of OS 10.5.2 is still not fixed. Basically, when using FileVault, the LaunchServices database is not read properly when you login to your FileVault account after a system restart (not just a logout/login â a full restart).
The reasons why it doesn't work are a little shaky, but basically, OS X fails to read the LaunchServices database and simply reverts to default settings. This means that any changes you make to the default applications -- changing your default web browser, RSS reader, FTP client, or changing which application files of a specific type are opened in -- will all be reversed as soon as you restart. The changes are, in fact, still present in the database, but they are not being read by the system.
Now, obviously, Apple needs to fix this ASAP, and I encourage everyone to submit a bug report on it. Until this happens, however, there is a fairly simple fix to force the database to be read on login.
To fix launch services, enter the following command in the Terminal:
This command must be run on every login. You can easily automate this using Automator, however. Simply launch Automator and select the Custom starting point. In the Actions search field, type Shell script, and drag the Run Shell Script action into the workflow pane. Paste the above command into the script window, overwriting any text already there. Save the Workflow as an Application and put it anywhere (I put it in /Applications/Utilities). Now, go to Login Items for your account and add the application you just created to your login items. From now on, the script will be run whenever you login, and all changes to your LaunchServices database will be properly loaded.
Note: I cannot personally take credit for this tip. The workaround comes from a this thread on the Apple Discussion Forums. Please remember to submit a bug report to Apple, even if you don't use FileVault. Apple seems to assign FileVault-specific issues a fairly low priority, and they need to know this is unacceptable.
Inside the 10.5 File » Open dialogue, as you probably know, you can use the Media category in the dialog's sidebar to browse iPhoto or Aperture photos. After you select an image, press the Space Bar to invoke a zoomed image view, showing the chosen image in a larger size. Once zoomed, you can continue to use the arrow keys to navigate your library while seeing the images in zoomed mode.
[robg adds: Given that this works with photos, I thought I'd try it with the Music and Movies sidebar entries, too -- and yes, it works for both of those media types (videos play within the dialog, and songs play, when you press the Space Bar) as well. So it seems it's basically like Quick Look in the Open dialog. I tried it with files outside the Media section, however, and it doesn't work there -- instead, it seems to toggle the Preview column between detailed and simple views.]
If you edit the info of files in iTunes and then launch Front Row while iTunes is still running, you will not see the changes you have just made. To fix this, quit iTunes after editing file info (you can relaunch iTunes straight away if you like; it makes no difference). When Front Row is next launched, the info will have been updated.
I don't know why this happens (I'd like to though), but I believe it is because Front Row is now an Application in 10.5. This is on OS X 10.5.2 with iTunes 7.6.1 (9), with "Keep iTunes Music folder organized" checked.
This took me a long time to figure out. There are some tips here and elsewhere providing fixes for FileVault problems caused by sparse image corruption. I discovered today that similar problems on Time Machine sparse image files were causing reproducible kernel panics (KPs) on remote Macs backing up to these sparse image files via a server Mac. The problem is that there's very little indication to lead one to that conclusion. I was getting predictable KPs as soon as Time Machine backups would begin, and none of the disks involved (remote computer, server computer, attached USB Time Machine disk) showed any problem at all with Disk Utility or DiskWarrior.
The solution was to log in as root on the server computer, and then use the following command to attach (but not mount -- this is key!) the image:
hdiutil mount -nomount -readwrite /Volumes/path/to/sparse/image
I then used DiskWarrior to rebuild the directory. (Disk Utility aborted with a sibling link error or something like that.) Without DiskWarrior, I would have had to delete the entire sparse image file and start a new complete backup series. This not only demonstrates an obscure vulnerability of Mac OS X 10.5.2, but once again reminds me I'm glad I ponied up for DiskWarrior. (More detail at can be found in this post on Apple Discussions.)
[robg adds: Obviously, this hint isn't something that's easily tested. It's posted more as an aid to those who may be experiencing kernel panics for no apparent reason. If you've seen such issues yourself, please post in the comments.]