I toggled a setting in Firefox a couple days ago and its tab/window behavior changed in a way that was exceptionally annoying. It took me a while to to find the now-hidden settings (who removes options only
from the UI?) to reset the behavior, so I’m recording it here for next time.
I want it to create a new window when an external app tells it to open a URL, and to use a tab when I click on a link that would open a new window from a page I’m already viewing (such as search results). That prevents apps like Quicksilver from opening tabs in the “last active” window that happens to be on another Spaces desktop, but also doesn’t clutter my screen with zillions of new windows as I browse.
FF 3.0.8 for Mac OS X has an option to tell it whether to open new tabs or windows by default:
to have separate options for what to do when an external application asked for a URL to be opened vs. when you clicked on a link on a page. I guess someone decided that was confusing. This Cnet article
describes how to turn it on:
The options for this behavior are shown at the top of the Tabbed Browsing panel in the Preferences window. If you ever feel the need to set this preference via About:config, look for browser.link.open_external. Setting this preference to 1 opens the link in the current tab and window, 2 opens it in a new window, and 3 opens it in a new tab in the front window.
Along the way I found another semi-useful setting via Lifehacker
that opens a new tab when you use the search box.
Type about:config into the address bar, and then put the following into the filter box: browser.search.openintab. Double-click the value to change it to true.
Now every search comes up in its own tab and I don’t lose any open pages.
There is a new release of AstronomyPictureOfTheDay
available this morning. Version 2.0 is a substantial rewrite of the 1.1 version, but retains essentially the same functionality. The primary difference is that you no longer have to run a script to “personalize” it during installation. Now that it is distributed as an Application instead of an Automator workflow, you can just drag it to your Applications folder.
The source is still created with Automator, but some of the Finder actions for working with directories have been replaced by Shell Script actions to perform the same operations. The Finder actions are hard-coded to specific folder names, selected in the Automator UI when the action is configured. With a Shell Script action, I can use environment variables such as “$HOME” to make the action more flexible. Using variables also avoids the problem of having everything in the workflow tied to my own home directory, so that the paths needed to be modified before the workflow was usable by anyone else.
I could, of course, have written the entire program as a shell script, Python program, or whatever. But the point of building it with Automator in the first place was that it was easy. I suppose I am stretching the boundaries of where Automator is the easiest tool for this particular job, but at least now the hack is hidden inside the app instead of hanging out where everyone can see it in the installation instructions.
is a perfect example of being too close to a problem.
Some users of the FlipStart compact PC were having trouble pressing the tiny keys for Ctrl-Alt-Del to login or reboot Windows. Unfortunately, the hardware vendor decided that instead of fixing the operating system so it wasn’t necessary to press Ctrl-Alt-Del on the tiny keyboard, they would just add a special Ctrl-Alt-Del button.