As described in the previous document on the KScript and KSWorld [6], we employ Functional Reactive Programming (FRP). Among other issues, FRP provides us a simple solu- tion for the problem. In KSWorld a states of a button such as the pressed state is manifested as a dataflow graph node specification. A dataflow graph specification can use mult- ple sources, and KScript allows to look at the “old value” of the variable. With this mechanism, we can concisely express the definition of such state variable. And, in turn, we can ex- press the other stream such as chaning the appearance of the

The first item on the list is to connect the events to more events to actions. In the LWorld, we implemented and used an event system that was derived from the Announcements Event mechanism [2], which is essentially a traditional ob- server pattern. In the LWorld, a handler that is installed to a Box to provide a customized behavior, say for a button, de- fines distinct methods for each kind of the user input events (such as buttonDown:, buttonUp, pointerMotion, etc.) and each of such methods is invoked as a callback. The prob- lem was the method had a mixture of code concerning the behavioral aspects and the appearance aspects of the button. At the same time, the code concerning a logical states of the button, such as pressed or entered states, are scattered across these callback methods and it was not easy to see the state transition occurs for such a variable.

Yoshiki Ohshima Bert Freudenberg Aran Lunzer Ted Kaehler

As each “Box”, the fundamental graphical entity in the system, is capable of direct manipulation, the programmer can build the appearance of a group of Boxes by directly assembling the Boxes and then provide scripts and layout specifications for them to make them complex graphical control. We illustrate how this is done to build fairly complex application with relatively small amount of code.

The main goal of the STEPS project is to think about the ways of reducing accidental complexity in making software. As the domain of our epxeriments, we chose the “entire per- sonal computing environment”, and have been writing var- ious software pieces [4]. The personal computing environ- ment discussed here spans from the low-level compiler that generates machine code to end-user applications, such as document authoring tools for end-users (imagine an Office- like application suite).

We had an earlier version of the same application called the “Frank” Document Editor, written in Smalltalk with our own GUI framework called LWorld [7]. From the experi- ence, we identified that the code we’ve written falls under three major categories:

yoshiki@vpri.org, bert@freudenberg.de, aran@acm.org, ted@vpri.org

Making Applications in KSWorld

Abstract

1. introduction

Viewpoints Research Institute

We also show that the system scales up well to write the universal document editor; about 10,000 lines of code was used to build the framework, the FRP evaluator, the docu- ment model and the document, etc., besides the implemen- tation of the special language created for KSWorld.

We report our experiments to create a GUI framework called “KSWorld”, which supports an interactive yet declarative manner of application writing. The framework embodies di- rect manipulation, high degree of loose-coupling and time- aware execution derived from the Functional Reactive Pro- gramming (FRP). We also describe how a universal docu- ment editor was developed in this framework.

• The connections between events and actions. • The construction of graphical widgets. • Specifying the layout of such widgets.

In this paper, we focus on the graphical user interface (GUI) framework called “KSWorld” and the universal docu- ment editor built on top of it. The document editor resembles an Office application suite in its appearance and the feature sets but it is powerful enough for the user to build his own applications.