SK8

For the television series, see Sk8 (TV series) and SK8-TV.
SK8
Paradigm object-oriented
Developer Apple Computer
First appeared Mid 1990s
0.9
Strong, dynamic
OS Mac OS
License open source

SK8 (pronounced "skate") was a multimedia authoring environment developed in Apple's Advanced Technology Group from 1988 until 1997. The project's goal was to allow creative designers to visually create a complex, working application. This was to be done by elegantly separating the concerns of visual design from programming. The main components of SK8 included the object system, the programming language, the graphics and components libraries, and the Project Builder, an integrated development environment. It was described as "HyperCard on steroids".[1]

SK8 was a research project that resulted in a variety of spinoffs (e.g., AppleScript, IPC for the Mac) and was used by Apple for system-level QA and for prototyping QuickTime and Newton, and by universities and corporations for creating and prototyping various tools and applications. Although around 1993 a team was assigned by the Apple Product Division to release a SK8 runtime, the limitation of the Mac's capabilities (mainly, low RAM and processing power) as well as the shift to the PowerPC chip made such a large project intractable. With the bulk of the original vision completed and no easy path to release as part of MacOS, active development ended in 1996-1997, and the Macintosh Common Lisp source code for the entire project was released to the public in 1997.

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 which could create derivative development environments that would themselves help creative designers to write complex and real programs visually.[2] The SK8 authoring environment would therefore act as a meta-development environment for building development environments for specific type of applications. The name of the project derived from his interest in skateboarding.[3] 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.[2]

Paradoxically, the early work on SK8 focused on infrastructure rather than visual programming. SK8's goal called for object-oriented technology beyond what was available at the time. Despite the severe limitations of the Mac Classic and later the Macintosh II, Kleiman decided—in the hope that SK8 would sometimes see the light of day—to develop for and in it. Kleiman's first efforts along these lines was a dynamic, prototype-based (like Javascript, but one in which properties were themselves objects) 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.[2] MacFrames was developed in Coral Lisp, which was acquired by Apple and became Macintosh Common Lisp.

The Macintosh at that time had no inter-process communication (IPC). Kleiman created the an IPC module for the Mac to allow MacFrames to communicate with other processes; in particular, with HyperCard. This allowed HyperCard to be used as a visual programming front-end for MacFrames, without additional effort. (This original IPC module was released as an init and adopted by others.)

Another goal of MacFrames was to build distributed processing right into the object system. The idea was that, instead of using an RPC API (e.g., RESTful services), one should be able to simply declare a property to be distributed; that is, it would know its endpoint and other properties. Thus, communicating with a remote process would be as simple as setting 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. This success permitted the SK8 project to expand.

Once the infrastructure was in place, the next goal was to develop the graphics object library. The idea was to develop objects from the most primitive level (points, lines, etc.) and create composite objects based on them. One design question was: how "heavy" would these objects eventually be? That is, to support as many conceivable uses of an object without additional programming, how complex would they become? The solution was to make them as heavy as they needed to be, but to hide the complexity through the visual programming development environment by managing the context. The logical conclusion was: SK8 would not just be a visual development environment; rather, it would be a visual development system development environment. In other words, development environments targeting different application areas would be built on SK8. Each application-oriented environment would manage the context under which a SK8 object's complexity could be hidden (or stripped away with smart SK8 object compilers that understood the interdependencies of each object's component). [NB: Adobe Air's ActionScript objects were heavy, but there was only one Builder for all applications, so truly visual programming was difficult.]

The first version of the SK8 graphics system had, as a test target, to extend HyperCard, but to allow cards to have multiple layers rather than a single "background" template. Around this time (1989), SK8Script (originally named AppleScript), a prototype for the first specification of the AppleScript language, was created. A number of researchers in the Advanced Technology Group began to use SK8 for their projects. Certain universities and corporations also began to participate.[2] 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.

A further idea was to create an infrastructure for glueing objects in some general but powerful ways, but by separating the concerns of the glue from the behavior and structure of the objects). Using metaphors like wiring and ports, objects could work in concert. The SK8 Project Builder was created to provide a very rich set of direct manipulation tools, including tools for building interactive controls and general but non-invasive glueing.[2] The builder's objective was to provide a visual/direct manipulation interface for building visual development environments.

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.

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,.[4] 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 affordances for meta-manipulation in a visual development environment.[5]

All SK8 Actors could contain other actors.[6] 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.[7]

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).[8] 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.[9] 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".[10]

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.[11]

SK8Script

Until 1989, SK8's scripting language was Lisp. Although powerful, Lisp was considered a bit arcane for the average developer. But apart from SK8's need for a simpler scripting language than Lisp, work on SK8Script (originally named AppleScript) was motivated by concerns about a growing number of scripting languages used at (and maintained by) Apple (there were four scripting languages used for various parts of Apple's ecology). A secret project had also started to modernize Mac OS; hence the design of this new, single scripting language for the Mac fell under its purview. Kleiman joined this project and, in collaboration with David Canfield Smith and Larry Tesler, designed and implemented the first version of AppleScript. While this version of AppleScript used SK8 objects that resembled the Mac, two years after this, the Apple Product Division hired a team to implement AppleScript for the Mac using AppleEvents as the glue for communicating with AppleScript objects—Mac resources and applications. At this point, management politely asked that SK8's AppleScript be renamed to something else; it took no creativity to name it SK8Script.

The basic ideas and syntax of SK8Script are evident in AppleScript, so no extended description is necessary except to understand that the objects in SK8Script's case are, of course, SK8 objects. There were aspect-oriented and other extensions to AppleScript, and SK8 objects were of course more sophisticated (e.g., smart properties), but other than that the SK8Script syntax was comparable with AppleScript.

There were two implementations of SK8Script. The first was based on Lisp and had only a Lisp debugger. This was replaced in 1992 by an assembler language version that had a sophisticated debugger with history and versioning for debug sessions.

Project Builder

SK8's Project Builder used custom windows and widgets, and did not look like any other IDE.

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.[12] 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.[8] The Object Editor that appeared listed the object's "properties" (instance and class variables) in one pane, and it's "handlers" (methods) in another.[13]

The GUI builder included a drag-and-drop based system for constructing visual objects.[14] 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.[15]

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.[16]

References

Citations
  1. ↑ Spohrer 1998, SK8.
  2. ↑ 2.0 2.1 2.2 2.3 2.4 Apple 1995, SK8 History.
  3. ↑ The application splash screen prominently features a skateboard.
  4. ↑ User 1994, pp. 211-213.
  5. ↑ User 1994, pp. 57-61.
  6. ↑ User 1994, pp. 203-204.
  7. ↑ User 1994, p. 205.
  8. ↑ 8.0 8.1 User 1994, p. 12.
  9. ↑ User 1994, pp. 76-84.
  10. ↑ User 1994, p. 4.
  11. ↑ User 1994, p. 26.
  12. ↑ User 1994, p. 11.
  13. ↑ User 1994, p. 15.
  14. ↑ User 1994, p. 20.
  15. ↑ User 1994, Chapter 4.
  16. ↑ User 1994, Chapter 19.
Bibliography
Related patents
Further reading

External links