Do you know how to reset all the metadata views back to their default designs?


The metadata view settings are kept in the user's Application Support folder. If you delete the file MetadataSets.plist, Aperture will create a new one with the default settings.

The Application Support folder in the Library which is inside the user's home folder. Aperture has its own folder. Mine looks like this:


This is also the home of many other settings for Aperture, including the keyword list, watermark images, and plug-ins. Sometimes these files are the cause of mysterious crashes on launch, so it can be a good test to rename the folder and relaunch Aperture to see if the problem goes away.

All these settings only apply to this user, note. There is another Application Support folder with an Aperture folder inside the Library on the boot disk. Here is mine:

BorderFX is here because it has an installer that put the plug-in in this central location. This gives access to the plug-in to all users of the machine. On my machine the Sample Projects folder is empty. That's because I trashed its contents after I had played with the images provided. It's worth checking to see if yours is wasting space and trashing the contents if it is.

Tags: Aperture, Q&A, Metadata, Metadata Views, Defaults, Plug-ins, Keywords

As currently written the plugin defaults to the same folder each time I run it. This is not convenient. There is a very good chance that I will want to go back to the same folder each time, so I added the exported file path to the defaults that are written to a read from the prefs file.

As part of doing that I changed -defaultDirectory to this code:

Here I check to see if the value read from the defaults (_defaultExportPath) is a valid folder using NSFileManager. If it is, then I use it, otherwise I use the built-in default of ~/Documents. This deals with the user moving or renaming the folder between runs.

Another change I have made is to make the Generate button do something. I decided that using the current date and time would make for a good salt value:

And here is the latest interface:

Note that since I am posting this after the plugin was released, this interface design is no longer current.

The other parts of this series can be found via the Cocoa page.

Tags: Aperture, Plug-ins, Random Wok, Cocoa, Defaults

[Note: my blogging this project is some way behind the development. Random Wok 1.0 has already been released.]

An inconvenience with the current version is that it always presents blank text fields to the user. I would like to store the prefix, postfix, salt, use salt, random format, random length, and alpha case selection somewhere so that their settings are retained from one run to the next.

Implementing this turned out to be harder than I thought it would be. After reading up on NSUserDefaults and looking at several examples, it all looked straight forward enough. But something very odd happened: the values I were successfully saving and restoring between runs was being stored somewhere, but not in the com.bagelturf.Aperture.Export.Random_Wok file as I had been expecting. Not only were they not in the expected file, the expected file did not exist. It was never created.

The values I was storing were actually getting put into Aperture's own preferences file in ~/Library/Preferences. While under some circumstances this would have been the desired behavior (such as writing my own plugins for my own application), in mine it was not. I could not use most of the NSUserDefaults methods because of this side-effect.

So I created two methods: -getDefaults and -setDefaults and inside them used -persistentDomainForName: and -setPersistentDomain:forName to read and write the complete plist file as a dictionary.

Setting the defaults (that is writing the file) is done like this:

It first accesses the shared instance of user defaults and then uses the bundle identifier to retrieve the settings into a mutable dictionary. That dictionary is then updated with the latest values from the ivars, suitably encoded, and written back to the file. This allows older versions of the plugin to work with newer versions of the plist file: anything not used is simply left alone.

Reading the defaults is much more involved. The extra work comes from the need to set up the file if it does not initially exist and to manage plugin version changes. The first part is much like before, with the addition of reading the version from the plugin bundle:

Then I deal with the first run. This is indicated by an empty dictionary:

This results in a file on the disk, and a mutable variable defaultsDict with the same information. Now I am ready to deal with a change of version number:

I have nothing to do: there is only one version so far. If the version has changed, then the new version number is written to the dictionary and out to the file. Finally I am ready to set up the ivars from the dictionary values:

I call -getDefaults from the -initWithAPIManager method so the ivars are ready to go when the window is created. Then in -willBeActivated I set up the various elements of the view:

Finally in -willBeDeactivated I call -setDefaults to write the current state of the interface to the plist file.

Here is what the final com.bagelturf.Aperture.Export.Random_Wok.plist file looks like:

The other parts of this series can be found via the Cocoa page.

Tags: Aperture, Plug-ins, Random Wok, Cocoa, Defaults