Plug-ins
Plug-in tutorialAbout plug-ins
If you've read any of AEP's documentation, by now you will be aware that plug-ins are necessary to make AEP do anything. Plug-ins let you add extensions to files and folders to encode or process them, let you remove them from files to decode them and let you change file extensions to translate one type of file into another. If you're looking for a certain plug-in, this is the page to try and find it. I will be adding more plug-ins as soon as I write them, or somebody else sends them to me.
Most plug-ins also need helper applications, which are also mentioned in the list. At present I recommend you download three of these especially. Firstly. Scott Anguish's Open Up. This free application lets you decode all kinds of compressed files and often does a better job at it then Aladdin Systems StuffIt Expander. When used in conjunction with AEP, it will also let you encode files to these formats!
Secondly and thirdly, get Peter Job's Nutcase Binhex and Nutcase MacBinary, which are also free. There still are enough Macintosh files out there that need to have both forks encoded and these two formats used to be the preferred way.
New plug-ins
- 1 July 2002:
The 1.0.5 release of AEP brings updated plug-ins for OpenUp and OS X Unix Encodings (both for adding and removing extensions), iTunes and Quicktime Player for translation. There are also new plug-ins for adding and removing gnutar and zip extensions. - 28 May 2002:
First release of AEP, no new plug-ins yet.
How to write plug-ins?
Writing a plug-in for AEP is quite easy if you know any Applescript. Those who feel somewhat insecure on that count, or just want to know a little bit more about writing plug-ins can read the tutorial. Those who feel confident enough, just need to know the following.AEP plug-ins are Applescript objects that are read in by the main application. You should therefore attempt to make them as short as possible. (But not any shorter!) Unless there is a compelling reason, try to limit the helper applications per plug-in to one. This will ensure that AEP functions as quickly as possible. Having to call on helper applications, makes it slow enough as it is.
You should supply two subroutines for AEP to call:
The WhatDoYouHandle() function is called, when AEP initialises the plug-in. (Or rather only when it detects new plug-ins have been installed. Otherwise it uses its preference file to speed up loading.) AEP expects this routine to return a record with properties of the plug in. The records differ for the different plug-in types. Note that the records use labels! You should be fine, by just copying the function from the relevant template.
Plug-ins that handle the removing of extensions need only to return two things: the extensionname, labelled Extensionname and a short description of what the plug-in does and which helper application it uses, labelled Desc. A plug-in that uses the application Magiczap to handle the removal of the file extensions "zap" and "begone" would have the following WhatDoYouHandle function.
The function for plug-ins that deal with the adding of file extensions has more items for each extension entry. You should also tell AEP whether or not the plug-in can be used with files, by providing the CanDoFi entry with a boolean. (Most plug-ins will.) Whether or not it can be used with folders, by providing the CanDoFo entry with a boolean. If the helper-application will turn supplied folders into a file, e.g. a compression application, by providing the All2Fi entry with a boolean. Finally tell AEP whether or not the plug-in can be safely used with files that contain a resource fork, by providing the CanDoRsrc entry with a boolean.
If you write a plug-in that deals with the translation of files by changing their extensions, you have to fill in the Extensionname, the CanDoRsrc and the Desc entries. The Extensionname should contain the file extension that the original file had, followed by a colon, followed by the file extension that the file will have after the plug-in is finished with it. So, if your plug-in will use Magiczap to turn "zap" files into "begone" files, your function will look something like this.
The DoYourStuff(CurrentItem, OriginalItemContainer, ExtensionToProcess) function gets called when AEP has noticed the user has changed file extensions and your plug-in has told it in the WhatDoYouHandle() function, it can deal with that.
As you can see, AEP will supply the plug-in with three pieces of information. The CurrentItem will be a reference to the file or folder that the user has made changes to. It will have the name it had before the file extension your plug-in deals with had been added or removed! So if the used turned the file TheCookies.txt into TheCookies.txt.begone, the file your plug-in will get is TheCookies.txt. The CurrentItem will be in a temporary folder, but AEP will also let you know the original folder it was in, using (tadaa:) OriginalItemContainer. Finally, AEP supplies the entire file extension the user added or removed from the item in ExtensionToProcess. If your plug-in handles more than one file extension, it can help you decide what to do. It is also usefull if the user added options to the extension, which AEP will not display in the file name of the CurrentItem. A good example of how to use these, can be found in the plug-ins that deal with the mailme extension. When AEP scans the file extensions a user typed, it will treat the first word after a dot as the file extensions and everything that follows until the next dot as its options. If you really need an option to an extension to contain a dot, you will have to ask the user to quote it, using double quotes. AEP will then treat it as part of the extension. Again, see the mailme plug-ins for examples.
When your plug-in has finished, AEP expects it to return either the file or folder as it is after processing, or one of four error codes, you should define in the beginning of the DoYourStuff function. These are:
-
WRONG_ITEM_TYPEwith a value of -1. Use this if the item type doesn't match one the plug-in can handle. At the moment, this will result in AEP telling the user that an error has occurred, so try not to use this one, but in the future things might change. -
ERROR_HANDELING_ITEMwith a value of -2. Use this if an error occured while processing the file or folder. AEP will then tell the user something has gone wrong, and to please help it to save as much as possible from this terrible mishap. -
CANNOT_TELL_YOU_RESULTANT_ITEMwith a value of -3. Again, use sparingly. In most cases your plug-in will be far smarter than AEP in figuring out which item to return. If you really can't, return this error, and AEP will try to do it for you. When it can't find the item, it will act like anERROR_HANDELING_ITEMhas been returned. -
DO_NOT_WORRY_BE_HAPPYwith a value of -4. In some cases, few I hope, plug-ins will deal with items in such a way, that nothing else can be done with them, e.g. deleting them or locking them into place. In these cases return this error, and AEP will ignore any other changes the user made to item. AEP will delete the temporary folder it created, so if you leave the item in there, it will be gone. Take care.
Yes, but were are the plug-ins?
To make access easier, the descriptions of the plug-ins have been divided over three pages. One for extensions you can add to files and folders, one for extensions you remove from files, and one that deals with extensions for translating files.