One of the many great things about OS X is the simple installation process most applications use. To summarise the process – “Simply Drag and Drop to Install”.
OS X has the concept of an application “bundle” (there are other types of bundles too, but I want to just talk about applications for now). An application has many files that work together – for example, there is the code that runs the software, there are images that are displayed, there are icons that are used, there are sound files that are played. The bundle concept puts all these files together in what appears to the end user as a single application “file”.
When you install the application, you drag it (the bundle) to where ever you want to install it. Often this is the Applications folder.
Now when it comes to delete, all you need to do is drag the file to the Trash, and empty it.
The whole idea is so simple and elegant. For most software there is no need to run special installers, or special programs to uninstall the application. Compare the whole process to that of Windows with install and uninstall applications.
Am I really clean of the software
There is one slight hiccup to the process. An application may create files that are not in its bundle. When you delete the application these files are still hanging around in your filesystem.
This isn’t a big deal generally. Most support files are very small – for example, almost every application will have a preference file. This file lives in your home area, under
Library/Preferences. If you ever have a look there you’ll see lots of preferences for applications you deleted long ago – in some case applications you don’t recall every running because you tried them once and deleted them almost immediately.
Some applications install files elsewhere when you run them. For example, in your home area, under
Library/Application Support, or perhaps even in your system library.
Further, when you use the application, it may store user files in certain locations. For example, it may store cache files in the
Application Support area, or your profile information.
For example, OmniWeb stores the following files in
Application Support (Firefox similarly stores profile information).
There are third party applications that support cleaning up on deletion, for example AppZapper, and clearly there is a market here as these applications are quite popular. However, it would be nice if OS X actually had the ability to clean up after itself without the need for third party tools.
Enter Trash Triggers
The idea here is simple. When you “trash” an application, the process of deletion should be able to “trigger” cleanup of the application (either automated or with user intervention).
For example, imagine I have been trialling Delicious Monster’s very cool software Delicious Library. Unfortunately I can’t afford it, or I don’t believe it is something I really need, so I place the application in my Trash, and empty the trash.
Delicious Library would actually leave behind the following files:
If I’m not planning to use Delicious Library, do I really want these files in my system?
Now, suppose emptying the trash could do the following. On finding an application to be deleted the operating system displays the following dialog (bear with me here – this is a mockup, and the dialog probably needs more thought on wording and button labels etc):
At this point, the user can choose to delete all the support files, removing all trace of the application from their system.
Now clearly not everyone wants to delete all traces. For example, I might be deleting Delicious Library for now as I don’t have room – but next month I intend to buy it and download it again. So I want my preferences retained. Therefore I can choose to just delete the application.
The result is an easy way to really clean up an application that was deleted through drag and drop.
How would this work
Below is a proposal on how this could work. These details are more technical, so only read on if you are interested in the internals of the application bundle and the way OS X operates on applications.
In my mind there are 3 types of support files:
- Application Preferences – a single file that stores the application’s preferences.
- Installation Support Files – files created after installation that support running of the software, for example kernel extensions, plugins, scripts to be run at certain times etc.
- User Support Files – file created by user interaction, such as cache files and user files that are auto saved.
An application, on deletion, could potentially delete any or all of these support files. Therefore, the solution should allow the developer to decide what is to be deleted.
The proposal is to add some new keys to the
info.plist in the application bundle. These key-value pairs indicate how deletion should be handled.
I’ve used keys with an
LS prefix (meaning Launch Services) given that many keys used by applications that relate to the running of the application use this prefix. It is quite possible that another prefix would be more appropriate.
In order to indicate you want to display a dialog asking if the user wants to delete all support files, the developer simply includes:
Where the value could be
ask – meaning to show the dialog, or
auto – meaning to delete as instructed without asking the user. The latter would be used for certain applications that don’t store user data but should clean up support files.
Preferences are easy. They are always in the same location, and based on the
CFBundleIdentifier key in
info.plist. You just need to use a key like
LSDeletePreferences with a
NO to indicate if you want the preferences deleted (if the user says to).
Installation and User Support Files
The Installation and User Support Files are more tricky. Basically, the developer may have stored files in
Application Support, or in another folder completely. They may have many different folders with support files too. In some cases they may need to do some processing first.
Here we could give the developer some choices:
- Delete all files in a supplied array of folders
- Run certain scripts in the application’s Resources folder (in the bundle) that clean up after some processing
- Make use of spotlight and metadata, and delete all files that match a given attribute
The first two are fairly standard strings in arrays in the
info.plist. OS X just needs to delete as required, or run the scripts in the order presented. In a similar fashion to the application preferences, a further key such as
LSDeleteInstallSupport would be used to allow the developer to say whether they will delete the Install Support Files (if the user says to).
The third choice is more interesting as it makes use of OS X’s Spotlight.
If the support files created by the application are tagged appropriately, OS X could delete all files with those tags. For example, suppose the following metadata attributes exist for files –
kMDUserSupport. OS X can search for all files with one of these metadata attribute and the value
CFBundleIdentifier, and silently delete those files. This isn’t dependant on file location at all, instead it makes use of the powerful metadata searching abilities of OS X.
So far Apple has said very little about Leopard (the next OS X release). We don’t know if there will be a new Finder, and we don’t know if Apple has thought more about uninstalling applications. I have proposed a solution that I believe maintains the elegance of drag and drop deletion, while still allowing applications to clean up after themselves. Even without the dialog, the ability to trigger deletion of support files when deleting an application would be useful. Once again, I’d love to talk more to Apple engineers about these ideas.
4 thoughts on “Improving Mac OS X: #3 – Trash Triggers”
OH NO A FEW KB OF TEXT FILES THAT DO ABSOLUTELY NO HARM ARE IN MY LIBRARY FOLDER :(!!!!!!!!!!!
Its simple and effective enough as it is, stop trying to complicated osx
Thank you Trevor for your input.
Trash Triggers would not complicate OS X. They only automate a cleanup process that should make things easier for people, and are no more complicated than the current process because the process can require no input from the end user and is automatic.
Perhaps the complication that you see is because I’ve confused you with the discussion on how a developer could set up a trash trigger to clean up. Once again, that is not for the end user to be concerned about – if you aren’t a developer, then don’t worry about that “complication”.
Once again though, I appreciate your thoughts.
Trevor, the cache files are usually more than a few kilobytes. Have a look at your ~/Library/Caches/ folder. Mine is 118 MB (Quicktime, Safari, and DashboardClient being the largest), which isn’t that big since I deleted the whole thing not that long ago.
Now, Apple recommends applications using this folder when needed, see [url]http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html#//apple_ref/doc/uid/TP40001411-109669[/url], but they don’t say anything about deleting the files afterwards. Hence the 90 items in my Caches folder.
I’ve thought about this idea too (briefly), in that my conclusion was that all of an app’s external files owned by it should be stated in a resource file; i.e. Info.plist. This might mean that applications might need to follow the recommended guidelines for external support files more closely (I’m looking at you, Microsoft Word).
Basically, the format goes: preference files in ~/Library/Preferences/, only app (non-user) centric stuff goes in here so it doesn’t matter if it gets deleted; support files in ~/Library/Application Support/, used for templates, plugins, global resources that the user can delete if they wish, and automagically saved data that is not managed by the user as external document files (e.g. contact list in Adium, messages in Mail, media in iTunes, bookmarks in Safari (although Apple like to have their own spot in the root part of the library for their apps)). Applications need to conform to this for it to work.
With assistance from the apps, I think this could be used for not only in uninstallation, but archival (backup) or portable purposes too.
Can I Trash my Caches in my Library??
Will this speed things up.
If not what will ?