SK8

History

The SK8 project was created by Ruben Kleiman when he joined Apple in 1987. He had come to Apple to develop a flexible, object-oriented user interface and multimedia development environment. The name of the project derived from his interest in skateboarding. Coincidentally, at this time the HyperCard, with its direct manipulation interface and scripting language, was about to ship. While HyperCard was great for simple applications it used a limited interaction model - the "stacks" of cards" - that limited its potential applicability. SK8 attempted to extend these benefits to a wider programming role.

Early work on what would become SK8 focused on infrastructure rather than visual programming. Kleiman's first effort was a dynamic, prototype-based object system, MacFrames, a frame/object system with plug-ins for inference engines. Through preferences settings, MacFrames was used to emulate a large variety of object systems, including IntelliCorp's KEE. This research, in concert with users developing actual applications and prototypes at Apple, yielded the object model used in SK8. MacFrames was developed in Coral Lisp, which was acquired by Apple and became Macintosh Common Lisp.

The Macintosh at that time had no generalized inter-process communication (IPC) system. Kleiman created an IPC init for the Mac to allow MacFrames to communicate with other processes, in particular, HyperCard. This allowed HyperCard to be used as a visual programming front-end for MacFrames. Another goal of MacFrames was to build distributed processing right into the object system. Instead of using an RPC API, one simply set the object's property with the desired value and callback for the results. MacFrames was used by Apple's QA group to create an automated black-box testing system.

The SK8 Project Builder was created to provide a rich set of direct manipulation tools, including tools for building interactive controls and general but non-invasive glueing. The builder's objective was to provide a visual/direct manipulation interface for building visual development environments. That is, the system could be used to develop completely different development environments tailored to different tasks. The first version of the SK8 graphics system was designed to extend HyperCard, allowing cards to have multiple layers rather than a single "background" template.

The SK8 system was initially programmed in Lisp. This was considered too arcane for general use. Additionally, there was growing concern about the number of different languages in use at Apple. As part of a wider effort to modernize the MacOS, a new unified scripting language was desired. In 1989 Kleiman joined David Canfield Smith and Larry Tesler to design and implement the first version of AppleScript. This version of AppleScript used SK8 objects, and two later the Apple Product Division re-implemented AppleScript using AppleEvents as the glue for communicating with AppleScript objects. The original prototype was then renamed SK8Script, and was itself re-implemented in assembler in 1992.

A number of researchers in the Advanced Technology Group began to use SK8 for their projects. Certain universities and corporations also began to participate. The system was used to develop prototypes for Newton, QuickTime interfaces, interprocess communication, and was used to prototype many titles, including Stagecraft, a learning tool for children.

For performance reasons, in 1992 and 1993 SK8 was re-implemented from the ground up. Working at Apple's Cambridge Research Center, the Macintosh Common Lisp object store was isolated and directly hooked into SK8's store. The SK8Script debugger was re-implemented at the assembler language level (previously in Lisp) and the compiler and runtime performance improved.

Description

The SK8 system includes the object system, the graphics and component objects, the SK8Script language, and the Project Builder environment.

Object System

The SK8 object system was, like Javascript, prototype-based, but unlike Javascript, object properties were themselves objects. Hence, properties were not simply names that acted as keys to values but in addition possessed arbitrary behavior. This allowed properties to have intelligent behavior (e.g., trigger an inference engine or serve as endpoints in RPC networking); one could think of them as "smart properties." The idea was to allow application programmers to focus on the manipulating objects rather than having to learn APIs—which would be built into the objects. Not implemented was a hierarchical namespace managing property names.

SK8Script

Until 1989, SK8's scripting language was Lisp. This changed to SK8Script, which was heavily influenced by HyperTalk (HT). Many of the differences between SK8Script and HyperTalk can be considered to be generalization of HT concepts, removing tight integration with particular objects in the HyperCard universe and replacing them with generalized syntax that could interact with any object.

Like HT, a core concept of the SK8Script system are the "containers", which roughly equate to objects in conventional systems, and the "chunking" system that allowed those containers to be identified and enumerated. HT had introduced the idea of offering multiple ways to address objects and collections, allowing the programmer to select whatever syntax seemed most natural in context, and then use an entirely different syntax somewhere else. SK8Script offered a similar system.

Graphics and Component Objects

SK8's universe was made up of a multimedia-oriented system using Actors on a Stage. Actors were any objects that were based on the prototype Actor object, which contained the basic framework needed to provide 2D graphics support - the location and size of the object for instance. Actors became visible when they were placed upon the Stage, an invisible background object that captured user events to provide interactivity. In SK8, a traditional window was an object like any other graphics object. When an Actor was on the Stage, it could behave as a window-like object. It was easy to design complex objects that behaved like windows (e.g., a donut-shaped window; its hole's opacity 0%, with content being a text object scrolling around or perhaps a movie playing within its frame). An object known as the "halo" provided resize handles and other widgets for manipulation in a visual development environment.

All SK8 Actors could contain other actors. The hierarchy could be navigated using the chunking expressions, so one could set the visible of the first Rectangle in CoolOval to true. The objects could then be made visible in the UI by moving them onto the Stage using the insert command, like insert CoolOval into the stage, which would make both the oval and rectangle appear.

GUIs were constructed solely from Actors. A window-like object could be built out of an opaque rectangle containing other objects (e.g., close buttons, widgets). Every Actor's drawing style was controlled by a Renderer, which aided the GUI building process. For instance, the BevelRenderer could be used bevel the edges around an Actor, producing an effect like Windows 3.x controls or the title bar in NeXTSTEP. Other renderers included color and image fills, gradients, tiles and blends. Although there was no difference in programming terms, basic objects like rectangles were classified "geometry actors" while more traditional GUI elements like buttons were known as "interface actors".

The Stage captured user-generated events like mouse-down clicks and key presses and sent them to the Actors. The visual hierarchy determined with object would receive the message first - the Stage was Z-ordered and objects closer to the front got the messages first. Messages could be passed up the class/prototype hierarchy with the do inherited command.

Project Builder

Project Builder was an environment for building visual development environments. It provided code editing, debugging, graphics and smart component library, runtime targeting support and a direct manipulation graphical interface builder system. A key element of the Builder system was the "Overviewer" panel, which held a categorized list of all of the objects in the currently opened project. These include libraries, user-created functions and methods, variables, and so forth. These could be examined and edited by double-clicking on them, or by clicking in an associated pop-up menu that appeared on the object when it was selected in the GUI builder. The Object Editor that appeared listed the object's "properties" (instance and class variables) in one pane, and it's "handlers" (methods) in another.

The GUI builder included a drag-and-drop based system for constructing visual objects. SK8 did not have traditional "screens"; it used an invisible "Stage" object that served as the background for managing events and visual objects. One interesting aspect was that no windows, in the traditional sense, were needed or expected to display anything. In fact, any visual object could have window-like behavior (through its drag-and-drop and other smart properties). SK8 did, however, include a system for editing and programming complete menu bars, a feature that HyperCard lacked. Another oft-requested feature from HyperCard was a media editor, which allowed Macintosh resources to be moved in and out of the project. SK8 built this functionality into the IDE. Other components of the system included an online documentation system, lists of systemwide objects and commands, and the code editor and debugger windows.

Interacting with the System

SK8Script offered a system for calling in and out of operating system functions, allowing it to more directly interact with the Macintosh Toolbox. In HyperCard, interacting with arbitrary Toolbox code was handled through custom code resources known as XCMDs and XFCNs which encapsulated the functionality in a black box. These were called and returned in a single operation, with the internal operations invisible. Under SK8, SK8Script could interact directly with the encapsulated code, setting variables, calling functions and returning results. External code could also call into SK8Script, examining and setting variables, or calling functions.