 |
||||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
 |
|||||||||||||
 |
 |
 |
 |
 |
 |
 |
||||||||
 |
||||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
Standalones for the Mac OS-challenged Original exhaustive work by Graham Samuel, The Living Fossil Co. (March 1997)
What this note is aboutAs every SuperCard developer knows, a SuperCard project can be turned into a freestanding application, also known as a 'standalone' or, of course, just an application. This is done using the Standalone Maker (tm) utility included in the SuperCard Developer edition. This tool combines your project with the SuperCard interpreter engine to create a well-formed, self-contained application which will start up and run your scripts when launched. This note is intended to clarify issues concerning standalones which are not covered in the Standalone Maker documentation, and which can confuse people who don't know a lot about the Mac OS and don't want to get to grips with any form of programming other than SuperTalk scripting. It was written by Graham Samuel as an exploration into the finer points of creating well-behaved standalone applications, and it has since been updated to cover SuperCard 4 and Mac OS X. The information may contain inaccuracies, so comments and corrections will be gratefully received. We assume that you have read the Standalone Maker documentation and that you are familiar with SuperCard scripting. We also assume that your Mac is running Mac OS 8 or greater. (We strongly recommend running the most recent versions of Mac OS 9 or Mac OS X, purely because those system versions offer the greatest stability and scope.) The emphasis in this note is on the creation of traditional Mac applications which contain things such as "File" menus which allow one to manipulate documents created by the standalone application. However, we begin with the simplest possible standalone. Topics covered are:
============================== 1. BNDLs, icons and binding
1.1 Type/Creator Pairs As explained in the Standalone Maker documentation, the MacOS uses the concept of a Type/Creator (T/C) pair to define a file as a program, and to define other files as being documents associated with ("bound to") that application. The T/C pair is implemented as two four-character codes. It seems that any printable characters (including spaces) are legitimate, but note that Apple has reserved codes consisting entirely of lower case letters for its own uses.
Applications always have a Type code of APPL and a Creator code which is your very own, representing the unique 'signature' of your application. Each document bound to an application (SA) has its Creator code, and a type code representing the type of data which you want it to be. Some type codes, particularly PICT and TEXT, are regarded as being universal and can be read by any program designed to read those data types. Others are private to your SA. Thus if you employ a PICT type of document, when a user double-clicks on its icon in the Finder, your SA will be started (or informed, if it is already open), because the Creator code 'binds' it to your application, and if you try to read it into, say, Photoshop via the "File" "Open" menu item, this will work too.
Each different T/C pair can have its own icon family associated with it. An icon family is described in 1.2 below.
The information about which T/C pairs exist for your application and what icons the whole caboodle uses are stored in something called a BNDL resource in the resource fork of your application. In the case of SuperCard, Standalone Maker looks after creating the BNDL resource, which you can look at if you are willing to use ResEdit. (You'll probably use ResEdit in the end, however scary it may seem.)
Note that, prior to Mac OS X, the BNDL resource of the standalone application is the only thing the Mac OS uses to tell the Finder how to display the icons and what is bound to what. None of this information is stored in the documents of your project - not the icon, not the binding information. All that goes in your doc is the T/C code pair. (Sometimes the Finder loses the info which it maintains about the BNDLs of individual applications, and this spells trouble for your desktop in the form of generic icons being displayed instead of the expected ones, and/or a failure to get an application to start by double-clicking on one of its documents - the situation can be recovered by rebuilding the desktop.) In Mac OS X filename suffixes such as .txt and .jpg provide another way of helping the operating system know what kind of file it is, and that can be enough for it to be opened in whatever application is designated as the default tool for that kind of file. However, it is wise to carry on using T/C code pairs, as this helps keep things (relatively) foolproof.
If you plan to distribute your SA at all widely, you should register your Creator and Type codes with Apple. This is quite painless if you have access to any browser - the URL for getting started is:
http://devworld.apple.com/dev/cftype/index.shtml
which is part of Apple's Developer's World site at:
Note that Apple will give you a list of the unallocated codes, but you can keep on querying their database until you find a free Creator code. Type codes don't have to be unique but should still be registered.
1.2 Icons and Icon Families in Mac OS 9 and earlier
The Standalone Maker requires you to provide icons for your application and all its document types. This is explained in the documentation. What isn't explained is that icons come in families. The family is necessary because the icon is obliged by the MacOS to appear in several forms, and each form can appear in two sizes; furthermore icons can be masked to indicate that the corresponding file is selected, in use or is offline. This obliges the icon designer to produce no less than 8 designs, viz:
The basic design, full size (32x32 pixels), in 8-bit colour (i.e. up to 256 colours) - this is the icl8 version of the icon; a small (16x16 pixels) version of the same (ics8); black and white versions of the above (ICN# and ics# respectively); 4-bit colour (16 colours) versions (icl4 and ics4); plus two masks, a full-size one and a small one, which define what the 'selected', 'open' and 'offline' versions of the icons look like - these versions are manufactured by the OS at runtime by combining the mask with the appropriate icon. The combining is done in three different ways, one to give the 'selected' look, one to give an 'open' look, and one to give an 'absent' look - this is like the different ink effects in SuperCard itself.
The best way to create a complete icon family is to open an existing one in ResEdit, copy it into a new document (typically a ResEdit document which you can use as a store for all your icons) and then modify it until it looks the way you want. If you have ready-made 32x32 pixel pictures you can paste them into the icon editor or ResEdit. The rest, including the uses of masks, is left for you to experiment with.
In Mac OS X icons can be 128x128 pixels and 24-bit colour, with 8-bit, 256-level transparency. This is dramatically better than anything achievable in earlier versions of the Mac OS. Try products such as Can Combine Icons, Pixadex, and Iconographer for creating these works of art.
|
||
|
|
|