If you'd like Safari 4 Beta's Top Sites screen to be your default home page, here's all you need to do. Open Safari 4's Preferences, and choose the General tab. In the Home Page box, enter topsites:, then close Preferences.
Your home page is now set as the Top Sites screen -- click the Home button in Safari 4's tool bar, and your current page will be replaced with the Top Sites screen.
One of the issues people are having with tabs on top in Safari 4 is that it's hard to distinguish which tab is currently frontmost. I found this an issue even with the previous location of the tab bar in Safari 3. The problem, for me at least, is that the Unified interface theme doesn't provide sufficient distinction between the tab which is frontmost and those which are in the background. I don't have this problem with the interface in other areas, like the Finder, and I suspect it's because windows don't get grouped as closely as tabs do.
My solution is simple and only takes me a few minutes:
Quit Safari then navigate to it in the Finder.
Control-click on Safari and select Show Package Contents from the pop-up menu. Navigate into Contents » Resources.
Make a copy of the following four files somewhere outside of the Safari package to serve as a backup: AW_ActiveTabCenterFill.png, AW_ActiveTabLeftCap.png, AW_ActiveTabLeftCapFirstTab.png, AW_ActiveTabRightCap.png.
Open the original files (within the Safari package) in your image editor of choice.
I added a two-pixel wide red border to each image as indicated here:
AW_ActiveTabCenterFill.png: Add a border only at the top.
AW_ActiveTabLeftCap.png: Add a border on the left side of the image. (I didn't add the border to the curved portion at the bottom left.)
AW_ActiveTabLeftCapFirstTab.png: Add a border only to the left side of the image.
AW_ActiveTabRightCap.png: Add a border only to the right side of the image. (I didn't add the border to the curved portion at the bottom right.)
I used a red color because I find it's easy to locate when I look at the tab bar, but it's not visually distracting the rest of the time. Others may, of course, prefer a different color.
For users of Safari prior to version 4, the same effect can be achieved by modifying these files in a similar way, though I find a one-pixel wide border is sufficient: TabBevel_Caps.tif (left, right and bottom edges) and TabBevel_Middle.tif (bottom edge only).
[robg adds: I tried this, and it worked very nicely, though I had to use PNG-24 to insure a transparent background. As an experiment, I took the editing even further, and replaced the entire gray gradient with something more colorful:
With a colored tab, I find the top tab bar location doesn't bother me nearly as much as it did when all the tabs were a near-uniform shade of gray. Because these files are under Apple's copyright, we cannot distribute modified versions, but only instructions on which files to modify.]
Many PDF readers will make obvious links (such as www.macosxhints.com and firstname.lastname@example.org) clickable. But for non-trivial links (like Mac OS X Hints), the PDF reader needs additional information to know what to refer to. Since Leopard, apparently, many Apple programs support creating clickable PDFs simply by using the PDF button in the Print dialog. So this is nothing new, but many people do not seem to be aware of this, so this might be worth a hint of its own.
Many non-Apple programs still depend on other methods. For example: this earlier hint explained that OpenOffice.org does not create clickable PDFs unless one explicitely uses the built-in Export to PDF function. Using the latter, one can click the table of contents to jump to some specific page, or click links to open a browser for an external web site.
As for web browsers, both Apple's Safari and the non-Apple OmniWeb (a free download since February 25th), create such clickable PDFs. Bottom line: simply choose File » Print, click the PDF button, and then select Save as PDF to create a PDF with clickable links. Or, if you don't want clickable links, then create the PDF using, for example, Firefox.
I wrote a small Ruby script which allows me to post my currently-active Safari tab on Twitter, including the possibility of adding hashtags. Here's the code, though you you'll find any updates to the script over here, and a bit more detail can be found in this blog post.
This script uses the RubyOSA bridge for AppleScript support from within Ruby, as well as quite a few other gems (why reinvent the wheel?).
[robg adds: If (like me) you're not a Ruby user, it will take a bit of effort to get this script to work. First, save the above as a text file somewhere on your path and make it executable (chmod a+x tweetsafari.rb). In order to get it working on my machine, I had to uncomment the require 'rubygems' line, and edit the twitter_user = 'your_twitter_username'. I also had to install some of the listed gems from the script. You can do this with the sudo gem install gem_name command. On my machine, I had to install rubyosa, shorturl, and twitter4r in order to get the script to work. Once I had all those bits, though, it worked as described, and tweeted a shortened URL version of my active Safari tab.]
Google recently added Tasks via a Gmail Labs add-on. I find this simple task list to be quite useful. However, it's tied to Gmail in that Gmail has to be open in a browser window for it to function. The "pop-out" feature is nice, but the Tasks lists automatically closes when the main Gmail window is closed.
Shortly after the initial launch, Google announced a version of Tasks optimized for mobile clients. If I had an iPhone, that'd be great, but I don't. However, I was able to exploit this to make a Gmail Task application!
I used Fluid to run the Gmail Tasks designed for the iPhone to get a simple task list that doesn't require you to keep Gmail open. Gmail Tasks for iPhone is only displayed for mobile broswers, so you'll need to swap the User Agent string in Fluid to make this work.
Create a Fluid App pointing to http://mail.google.com/tasks (Google Apps users should use http://mail.google.com/tasks/a/YOURDOMAIN). The first start-up will fail, because you need to swap the User Agent to Mobile Safari. In your Fluid app, under the application menu, choose User Agent and select Other... and put in the User Agent String for the current Mobile Safari:
Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20
Restart your app and you're done! A more in depth write up with pictures is on my blog.
There are a few things in Firefox that just do not satisfy my needs, and they're the reason I have not made Firefox my default browser. One of those issues is the handling of the Bookmarks Toolbar. In Firefox, unlike Safari (Command-1, -2, etc.), there aren't any hot keys assigned to the Bookmarks toolbar. While this has generally not been a problem, I still find myself wishing I could use my bookmarklets with the ease I have found in Safari.
The following is a guide, through the use of an external add-on, to add Safari's functionality within Firefox 3. Theoretically, these steps should be reproducible on Windows, Linux, and Mac systems. However, I have only tested it on my Mac, and the location of the .js file that needs to be edited will most likely vary.
If, like me, you hate it when your MacBook's fans start to whine while watching YouTube, you should skip Safari (even 4.0 Beta) and try OmniWeb (now a free product) or Camino instead. A comparison of the Activity Monitor results, using the same video in each browser, showed these figures:
Safari 4.0 Beta
Window Server 12%
Window Server 5%
Window Server 5%
Here are some screen grabs showing each browser's performance. Further remarkable is the fact that Camino split the workload across the cores nearly evenly. I tested on a Macbook 1.83GHz Core 2 Duo with 2GB of RAM running OS X 10.4.11.
[robg adds: I did a quick test using my 2.66GHz Quad Core Mac Pro (running 10.5.6) and an HD-quality video on YouTube. I also added Firefox to the mix, and my results were a bit different than above. On my machine, for the video I was testing with, Camino was also the clear winner at around 80% CPU usage. However, there wasn't any notable difference between OmniWeb, Firefox, and Safari 4.0 Beta -- all three were in the 115%-125% range. More experimentation is needed, but it definitely seems that Camino does the best job of minimizing CPU usage during Flash playback.]
I have found that it can be really annoying trying to get Google Gears to work with Safari. I was able, eventually, to get Google Gears version 0.5.15.0 to work nicely in Safari 4 beta. The install and update process, however, is somewhat of a mess. I had Gears installed with Safari 3, and found that I had to manually remove it first by running this command in Terminal:
After uninstalling, then you can go back to the install page and re-install the latest version for Safari 4 Beta. Now enjoy offline Gmail, Gcal, and Google Reader in Safari 4 Beta. I don't know if this version works in Safari 3 though ... does anybody else know? Please chime in below.
To get the circular progress indicator back, you need to set the DebugSafari4IncludeToolbarRedesign preference to FALSE, and leave (or reset) the DebugSafari4LoadProgressStyle preference to TRUE (its default setting). So if you haven't modified either of these settings yet, you just need to do this in Terminal:
With the prefs set in this combination, you'll get a pie chart on top of the favicon that fills in while a page is loading. (I originally wrote about this on my blog, if you want or need more details.)
[robg adds: I confirmed that with this mix of settings, you do indeed see the round pie-chart-style progress indicator in Safari 4 Beta.]