TinkerTool review: Adjust hidden Mac settings
One thing that makes Mac OS nice to use is that it doesn’t have a million pointless preferences to tweak. The same is true for the apps that come with the Mac. Fun though preferences are to mess around with, too many settings tend to clutter up the interface and get in the way of real work.
However, many users like a bit more control than the Mac gives you out of the box, which is why Apple and other app developers often include “hidden” preferences in their apps. Such preferences aren’t settable in an app’s Preferences dialog, but you can adjust them by editing .plist (property list) files or by using the defaults
shell command.
That’s all very well, but many users aren’t comfortable editing complicated settings files or running shell commands. What’s more, how do you find these extra preferences, if they’re not in the Preferences dialog?
TinkerTool to the rescue
Enter preference-tweaking tools like TinkerTool. This free app gives you a nice graphical interface to many of those squirrelled-away Mac OS and app settings.
The preferences are grouped into 9 tabs:
- Finder lets you adjust various hidden Finder settings, turn off some Finder animations, and so on. You can even add a Quit option to the Finder menu (yes it is possible to quit the Finder!).
- Dock controls things like changing the appearance of the Dock, as well as positioning it to the left or right, rather than in the middle.
- General is a bit of a catch-all tab. You can control where to place scrollbar arrows; tweak screenshot settings; adjust the way that sheets work; alter the number of Recent Items entries (or turn off Recent Items altogether if you work for the CIA); and change the delay for initiating text dragging actions. You can also toggle the Dashboard, as well as the Dashboard’s developer mode.
- Applications lets you tweak various apps such as Address Book and Terminal, configure disk image handling, and decide what to do if (or should that be when!) an app crashes. You can also add an eject button to the menu bar (though frankly I prefer the media eject key on the keyboard).
- Leopard adjusts various 10.5-specific settings, including those for Spotlight, Spaces, and Time Machine. You can also adjust hidden iTunes 8 prefs here.
- Fonts lets you adjust various system and application fonts (see below).
- Font Smoothing lets you control the font size at which anti-aliasing kicks in.
- Login Items is much like the list in System Preferences > Accounts, but gives you the additional option of temporarily disabling items while still keeping them in the list.
- Safari adjusts a plethora of Safari prefs, such as toggling the Develop menu, altering the way PDFs are displayed, and fine-tuning the browsing history.
There’s also a Reset tab that lets you restore your preferences to the state they were in before you fired up TinkerTool, or back to the system defaults. Handy if you get your prefs in a mess.
Top tweaks
While many of TinkerTool’s settings have little practical use – which, presumably, is why Apple made them hidden preferences – many others can help to improve your Mac experience in small ways. Some of my favourite tweaks include:
- Dock > Use transparent icons for hidden applications: When you hide an app with this option selected, its Dock icon turns semitransparent. This makes it easy to see at a glance which apps you’ve hidden, and puts their icons subtly in the “background” so that you can concentrate on the icons for your currently-used apps.
- General > Accelerate animation when rolling out sheets: Sheets are those dialog-like panes that roll out from the top of the current dialog when a button is clicked (such as Advanced in System Preferences > Network). They normally take half a second or so to roll out and back in. With this option selected, this time is reduced to a fraction of a second. Can’t beat saving a bit of time!
- Applications > Terminal: Auto-activate windows by mouse cursor: Speaking as someone who usually has several Terminal windows open, this is a real boon. Normally, to switch Terminal windows, you have to click the new window with the mouse (or use the Command-` shortcut). With this option selected, you can just move the mouse cursor to the new window to activate it and start typing. The only drawback is that you can’t switch from another app window to a Terminal window this way.
- Leopard > Help Viewer: Don’t keep help window in the foreground: I can see why Apple decided to keep the Help Viewer window always on top; however it can really get in the way if you have a lot of apps open. It’s great to be able to have this option to disable the “always on top” functionality.
- Fonts: OK, I take back one of my comments in my 10 ways Windows beats Mac OS post. I had no idea that you could in fact change the fonts used by the Mac OS UI. They’re just hidden settings, that’s all:
Summary
Overall, TinkerTool is a useful little app that saves you burrowing around in .plist files and the Terminal in order to tweak hidden preferences. While it doesn’t access anywhere near all the hidden Apple prefs – and some of the settings it does let you tweak can be adjusted within individual apps anyway – TinkerTool gives you a fairly decent range of settings to play with. It would be nice to see more preferences, though, and to see the preferences grouped a bit more logically across the tabs.
If you’re interested in this sort of app then you might also want to check out TinkerTool System and Onyx (useful for system maintenance as well as in-depth tweaking), and also MacPilot (which lets you tweak practically any setting under the sun).
[TinkerTool version reviewed: 3.93]
January 9th, 2009 at 1:13 pm
Are any of these data driven?
By that I mean that I think a tweaker should perhaps
be _just_ a tweaker, something that potentially
handles anything that is a single independent setting.
It should be almost totally data driven, with a simple GUI (categories, subcategories, value validation); all
data living in a plist. Also extensible, with plugins
for different mechanisms (defaults, launchctl, etc);
the plugins would deal with temporary vs permanent
(if applicable), and there might be additional
plugins for value validation beyond that common
for value types appearing in plists, and for
applicability verification beyond what would
always be done (OS version) and what would
always be done by a particular plugin.
The data would include basic applicability
description, mechanism, mechanism-specific
elements, GUI placement (category, subcategory),
date added, and some sort of UUID. The data would be
user-extensible through the GUI, and could
optionally be submitted to a central database
of candidate updates, in return for a UUID;
if a submission was accepted and redistributed,
it would retain that original UUID and on update,
replace the user’s original entry (for uniformity);
this would require that the “how” details were
unchanged (GUI placement and descriptive text
might change). Validation of candidate updates
and data maintenance (consolidating entries
for individual OS versions, for example) would
be done by a set of “trusted” volunteers. Candidate
updates, approved updates, new plugin distribution,
all would use distributed infrastructure; all updates
would be signed, and the plist would have
a three-part overall version number (major=
incompatible changes, minor=compatible changes
that may require new plugins or plugin updates,
micro=updates that don’t require major or minor
version changes), as well as a timestamp.
Resource editing might also become a plugin.
By being run in a batch form at system or session
startup, this could optionally make persistent any
tweaks that would otherwise be non-persistent;
an additional message should be present if there
were undue risk of painting oneself into a corner
by doing that.
Security and privileges should be honored; non-admin
users should only be able to change their own settings, while admin users should where applicable
have a choice of scope.
The only fundamental limitation is that each tweak
should be something that can be adequately validated independently of any others. Even that could perhaps
be circumvented by validation plugins, that would
only allow certain settings to be changed in
reasonable combination; but then all the value
fields would have to be able to fit onto a single
line in a list view in the GUI; the schema could
accomodate that with the use of appropriate
combinations of dictionaries and arrays.
Ideally, once it was bug-free, there would be
no need for changes to the basic program, only
data maintenance and occasional new plugins.
This mechanism would take advantage of
distributed knowlege; as new tweaks were submitted,
the program would grow ever more capable. And
since each record had a timestamp, one would
be advised of new tweaks as they were distributed.
Seems to me that 90% of the work would be getting
the schema right; the rest would follow.
The only problem is that either someone pretty
big would have to do it all (if it were commercial),
or the support would have to be from a large
pool of volunteers (if it were free), because the
support infrastructure really needs to be distributed
for updates to be verified and distributed promptly
and with high availability.
No, I haven’t used XCode enough (i.e. at all) to
whip out something like that reasonably quickly;
and I don’t have the time right now to flesh out the
design, and then either learn XCode or do it
the old-fashioned way (Makefiles and hand-coding).
However, I hereby grant a free license to anything
unique I might have mentioned, for anything
distributed free and open source. Any other rights
are negotiable.
The data acquired by such a tool could also be used
by other tools, that simplified matters by being
“smart” about tuning for certain objectives
(performance, choosing look and feel options that
were as much as possible like some prior version,
etc). Ideally those would also be open as to what
they did, but would not necessarily be free or open
as to their code (even coders have to eat, pizza&beer
isn’t usually free).
January 13th, 2009 at 6:34 am
I don’t think any of the current tools work in this way. It’s a great idea though! 🙂