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:


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]

Bookmark this post:

2 Responses to “TinkerTool review: Adjust hidden Mac settings”

  1. R. Hamilton Says:

    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).

  2. Matt Says:

    I don’t think any of the current tools work in this way. It’s a great idea though! 🙂