Last month, in Parts I and II of this tutorial series, we began our exploration of the world of preference (.plist) files. I explained what .plist files are, what they do, and where on your drive you can find them. Finally, I described how to open and view the contents of these files. With this installment, we detail with the answers to the critical why question about .plist files:
PART III: Why bother to view or edit .plist files?
Q. As covered last month, the most common use of .plist files is to store changes that a user makes via the Preferences dialogs of applications. Other changes to .plist files typically occur automatically, such as when you resize or move a window, with no need to access the file directly. Given this: why would I ever want or need to view a .plist file?
A. The answer is that there are preferences settings of interest that can only be accessed by opening the relevant .plist file. As examples:
- Go beyond the limits. Example: In the Dock System Preferences pane, there is a Magnification slider that goes from Min to Max. However, it is possible to enlarge the magnification beyond the Max in this slider. To do so, however, you need to edit the com.apple.Dock.plist file.
- Expand your options. Example: When you select to connect to a server, you are typically given the option to login as a Guest. Apple has provided a way to disable this guest access, if you wish. It is done via a property listed in a .plist file. There is no user interface to this property; you have to do it from the .plist file itself.
- Access "hidden" options. Example: Check the application (Finder) menu of the Finder. Unlike almost every other application, it has no Quit command. This makes sense, as you would rarely want to quit the Finder. But there are few occasions, mainly related to troubleshooting, where quitting the Finder is helpful. However (ta da!), there is a hidden .plist setting, in the com.apple.finder.plist file, that allows you to add a true Quit command. Once again, adding this setting requires direct access to the relevant .plist file.
Note: You cannot truly quit the Finder via a Force Quit. If you try, the Finder indeed quits, but then immediately relaunches. If you want the Finder to stay quit, you are out of luck with a Force Quit.
Q. Hidden items? Can you explain more clearly what you mean by this?
A. Sure. What I mean is that, even if you opened the relevant .plist file, you would not find the property listed. It is entirely missing, unless and until you add it.
Q. Wait a minute. If the property is missing altogether, and not documented anywhere, how do I learn that it exists?
A. Yup. That's the question that everyone gets around to asking sooner or later. The answer is that the developer of the software, of course, knows about these properties and he can communicate their existence in various ways:
- It might turn up in relatively obscure documentation, such as an Apple Developer tech note. For example, buried in this Apple Technical Note are the details of how to use a .plist file modification to enable Dashboard's developer mode (a subject we will explore more in a future segment of this series).
- Otherwise, the developer may post the information in his personal Weblog or tell it to someone else who similarly posts it on the Web.
Whatever the route, the tip eventually winds up getting circulated among mainstream Macintosh Web sites and magazines, such as here at MacFixIt. And that is how most people eventually learn about it.
Q. That seems so hit-or-miss. Are you sure there isn't some place, such as somewhere inside an application's package, where I could be sure to find a list of all possible .plist settings for that application?
A. Sadly, no. The cold truth is there is no sure way to find out about hidden settings.
You may occasionally get useful results by applying the Unix strings command to an application's code. Skipping over the details, this command lists all readable text contained within the selected code. This might reveal the name of a hidden .plist property. But there are no guarantees. Personally, I almost never have success with this method.
Q. So why do developers do this? What's the point of keeping these things hidden?
A. The precise point varies. But the general rule is that these settings are intended only for a limited audience (such as developers or advanced users), and so they are hidden to prevent the rest of us from messing with them.
Q. If a hidden property is not included in the .plist file, how does the application know what its value should be?
A. Even hidden properties have a built-in default value. For example, an option to enable a hidden developer mode would typically be set by default to "no." This means that, even if the .plist property is not present, the application "knows" to have developer mode turned off by default. So there is no harm done by not listing these hidden properties. It's only if you want to change a value from its default setting that you need to know about the hidden property.
By the way, some properties that appear to be hidden are really not. Or at least not in the sense that I am talking about here. Let me explain. If you check the Dock System Preferences pane, for example, you will see a number of settings. However, if you open the com.apple.dock.plist file, you may not find a property that corresponds to each of these settings. In this (and other similar cases), the property is typically missing because it does not appear in the .plist file until the setting is changed from its default value. Because changing the setting can easily be done from a Preferences dialog or pane, I don't consider this a true hidden setting.
To see what I mean about these not-really-hidden settings, try this:
- Go to ~/Library/Preferences and locate com.apple.dock.plist. Rename it ~com.apple.dock.plist.
- Go to the Dock System Preferences pane and make a change. For example, from the "Minimize using" pop-up menu, select Scale Effect instead of Genie Effect. If you now look in the ~/Library/Preferences folder, you'll see that a new file named com.apple.dock.plist has been created.
- Open this new file in Property List Editor (see last month's article if you need help in doing this). You'll see that there is only one property listed (mineffect), the one that you just changed, and its value should be "scale." The point is that this property was not added to the .plist file until you changed its value from the default (genie) setting!
- Compare this to the original (just renamed) .plist file. For example, in my case, there are several dozen values listed in the original file. Most of these first appeared as I made modifications to the Dock settings or the Dock itself. Because I had never previously changed the "Minimize using" setting, there is no mineffect property in this list.
- Close both .plist files.
- OK. Now delete the newly created com.apple.dock.plist file and give back the original name to the renamed file. This gets you back to where you were before our little demonstration began and makes sure that you don't lose any of your previously created Dock setting modifications.
Figure 1. (a) The Dock System Preferences pane and (b) a newly created "default" com.apple.dock.plist file, after modifying the "Minimize using" property.
Note: If you are feeling a bit more adventuresome, try this:
- Before doing Step 6 above, launch Activity Monitor. Locate the Dock process and click the Quit Process button in the Toolbar. The Dock should quit and immediately relaunch. However, the Dock will now likely look quite different. This is because its settings are based on the newly created .plist file, not the original one.
- Now re-open the newly created active com.apple.dock.plist file. You will find that several new properties have been added. This represents the full set of (normally visible, not hidden) default settings. They get added to the .plist file when the Dock is launched for the first time (or, as in our case, when the Dock is launched and detects that the default properties are missing from its .plist file). Most applications store a set of default .plist property values. If you delete an application's .plist file, these defaults are used to automatically create a new .plist file with all the application's default settings intact.
- Close the .plist file. Follow Step 6 above. Then Force Quit the Dock again. All your old settings should now return.
Q. You said that Apple provides no way to modify these hidden settings, except by directly editing the .plist file itself. What about shareware and freeware utilities? Do they help?
A. Most certainly. As the Mac community discovers various hidden .plist settings, there are a host of utilities that get updated to add the new settings to their list of features. Two of my favorites are TinkerTool and Cocktail.
For example, you can add a Quit menu item to the Finder (as discussed above) by simply enabling a checkbox in either of these utilities.
Figure 2. TinkerTool's option to add a Quit menu item to the Finder.
But let's be clear. All these utilities are doing here are making the exact same .plist changes as you could do yourself. They just simplify the process by doing the change for you.
The advantage of using Property List Editor (PLE), instead of these utilities, is that you can make any change you want, not just what these utilities choose to provide. And you can do it all with one free utility, instead of several shareware programs.
Still, there is no denying that these utilities are often more convenient that using PLE. Personally, I use both. Which I prefer depends on exactly what I am trying to do, and sometimes just what mood I am in.
Q. OK. Enough of the "why" questions. Before ending this segment of the tutorial series, how about giving the specifics on using PLE to make at least one of the changes you covered here today?
A. Be glad to. And by the way, in future installments of this series, I will provide the full instructions on how to make all of the .plist changes covered in this article. For now, as one example, I'll show how to add a Quit menu item to the Finder:
- Open com.apple.finder.plist in PLE.
- Click the disclosure triangle to the left of the word Root. This reveals all of the properties in the file.
- Click the New Child button.
- Replace the text that reads "New Item" in the first column with "QuitMenuItem."
[Note: If you already have an item with this name, you will get a warning message asking whether or not you want to replace the existing item. I am assuming that you do not have this item already.]
- In the Class column, select Boolean from the pop-up menu.
- In the Value column, a pop-up menu should appear with Yes and No as the two choices. It should have Yes selected by default. Leave it that way.
- Select Save from the File menu to save your changes. You can now quit PLE.
- Holding down the Option key, select the menu for the Finder icon in the Dock. One of the choices should be Relaunch. Select it. You need to do this for the change to the .plist file to take effect.
- Now go to the Finder menu. There should be a Quit Finder item at the bottom of the menu.
Figure 3. The "QuitMenuItem" property, as view in Property List Editor.
Figure 4. The Quit Finder item in the Finder's Finder menu.
To see what happens if you use this command, select it and watch the Finder quit. You can reopen the Finder simply by clicking the Finder icon in the Dock. To remove the command, simply select the QuitMenuItem property in PLE and click the Delete button (alternatively, you can change its Value to No); once again, save the com.apple.finder.plist file and relaunch the Finder.
Whew! Last month, I promised that this installment would cover how to interpret .plist files and edit their content. Well, we did get into this a bit with this example. But it is hardly the full story. It turns out, answering the why questions here took much more space than I anticipated. So, the full story on interpreting and editing .plist files will have to wait until next month's installment. See you then.
Like what you've found in this tutorial? Get more troubleshooting guidance (updated daily) by subscribing to MacFixIt Pro.Resources