oster@lapis.berkeley.edu (David Phillip Oster) (10/02/86)
One of the great things about the mac is that the major applications all share data on the fly. Select copy on the Edit menu (and the guidlines are very firm about requiring an Edit menu of a particular form in all editors, be they video, or audio editors.) and data is placed in an area of memory called the clipboard. Desk accessories, other applications running simultaneously under switcher or servant, or other applications running later, can sense that the clipboard has changed, and read the data in. The data is in a mini-IFF like format. The problem is that Apple forgot to include a way for an application to detect what data format its listeners like. For example, a word processor has to copy to the clipboard in both MWRT (fonted text, standard) and TEXT (ascii, standard) so that both other word processors, and also more limited editors can pick up the text. MWRT includes tab and margin information, and allows individual characters to differ in their fonts and styles (bold, italic...) TEXT is just the straight ascii. In a multi-tasking environment, an application could poll for listeners, and negotiate with them about formats. It would have to write in ALL its formats only when it was quitting (since any appliction might come up then to read the data.) All successful word processors on the Mac understand TEXT, MWRT, and PICT. All graphics editors understand PICT and at least TEXT. All text editors at least understand TEXT. The uniformity of use of the clipboard makes software on the mac seem like an integratable application: everything just works together smoothly with everything else. I've made use of this to write a system that uses MacDraw as a subroutine. I've just finished writing a system that uses the clipboard and switcher to run with a graphics editor: you draw screens in the editor and import them into my system with a single control character. (this importing is an artifact of the clipboard stuff above. It requires no extra work for an application to use it.) my system parses the picture looking for a picture of a gadget. Pictures of gadgets just work. Now when a gadget works, it has to do something. What it does is conveyed by a directive in a font called "proofmark". The name comes from "Proofreader's Mark" a proofreader's mark is a directive from an author to an editor about the presentation of material to an end-user. The user doesn't see the mark, but the editor does, and it tells him how to treat the material. So a proofmark tells my system what to do when a user clicks on a gadget. My system also provides a pictorial database capability, so you can work with many pictures, each as big as a screen, simultaneously without getting lost or confused. My system does not need to provide any editing capability of its own. You can do anything you want in the graphics editor, so why duplicate functionality? I can switch between the editor and my part of the system in under a second. (I am belaboring this point because many of the Amiga readers out there don't know about Switcher.) My system was written for the department of education at here at Berkeley, to allow non-programmers to do interactive tutorials. It can also be used to do almost running mock-ups of new applications. The only reason it works is because of the single key-stroke integration of my system with existing graphics editors. And I don't even have real multi-tasking! Multi-tasking is fine, but give me inter-operability any day. Questions: Do most amiga word/graphic/sound editors use the clipboard? If no, why not? If yes, how do applications negotiate for clipboard data? What should I call my system? (I need a good name to do the icons, and I need icons so that you can double click on one of my applications data files.) I had to devise my own picture parsing algorithms. Has anyone else done work in this field? (I see the picture as a list of graphics calls. Most work on pattern recognition assumes a 2-d raster.) --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@lapis.berkeley.edu -- build something that will last at Uucp: ucbvax!ucblapis!oster -- least until we've finished building it."