this paper we show how a text editor can be extended to include active text elements and give examples for how to apply these facilities to source code. Our approach is different from that of syntax-oriented editors in that our structuring is not based on the syntax of the edited texts. The implementation was done in the Oberon system which offers powerful mechanisms for extending software in an objectoriented way. KEY WORDS Active Text Hypertext Documentation Program editor Event trace diagrams MOTIVATION For centuries text was exclusively stored on paper. It was passive information that could be read or written, but nothing else. With the advent of electronic text processors operations such as inserting, deleting, and searching were introduced. But still text was passive in nature. Now that high-speed computers, graphical user interfaces, and multimedia become common, one starts to break with the passive paper metaphor and begins to consider text as an active medium.

Using icons as handles to objects allows for a new simple design paradigm for user interfaces. The key is a concept that inherits icons from graphical user interfaces and the interpretation of sequential text from traditional text interfaces. The basic tool is the object oriented text model. It is shown what power lies in the introduction of icons into text as well as how icons can be used in a better way, if being seen in some context. An implementation of the concept and some application examples are described. Introduction The world of user interfaces splits into two paradigms: Text based and graphical user interfaces. It is a tradition to consider these two paradigms as completely different. But, modern text editing systems have already proven that this is not true. At least, text systems based on text attributed with fonts, size, color etc. and supporting a pointing device like a mouse for input, have many aspects of a graphical user interface. Still, the basic data structure is ...

. Knuth's Literate Programming system allows an author to design and describe a program hierarchically according to the method of stepwise refinement. The result is source code, which can be read sequentially like a book, section after section. This helps when reading printed source code, but on screen source code is read rather selectively like an encyclopedia. There the programmer wants a system which allows, possibly even encourages, selective browsing; zoom in at interesting points; jump to other locations according to control flow or other semantic relationships. This is the approach chosen by hypertext systems. In this paper, we demonstrate a solution, called Reverse Literate Programming, which combines the advantages of Knuth's method and of the hypertext approach. We implemented active text elements making it possible to have the source code as a hypertext screen document. A special command prints this document as a Literate Program, i.e. an essay, including documentation, pict...

This paper illustrates an object-oriented approach that allows for both contour and rendering independence. Refined solutions can be packaged separately into intelligent contour and rendering objects. The approach results in a small and efficient font-scaling system that masters complexity by concept rather than industriousness.

Introduction and Overview At the beginning it was just a vision. A vision with many different facettes like electronic textbooks with integrated active elements, a versatile platform for the use and design of expressive graphical user interfaces and a new paradigm of how to look at software that is based on completely autonomous functional units, so--calledend--user objects. The vision was still rather diffuse when we turned it into a project, and it was by no means clear, if this was really just one project or actually a series of more or less independent projects. Among the few more concrete aims, let us pick the crucial topic "separation of application and user interface programming". The principle we had in mind is simple. It is illustrated in Figure 1 with the example of the simulation of a waiting line. The essential point here is that the application program (the simulator) is kept absolutely independent of any kind of display (the panel) because it ope

Kurzfassung 1 1 1 2 2 2 Background Information 5 Oberon-2 5 Control Flow 7 Control Flow Graphs 7 Dominator and Post-dominator Trees 8 Control Dependences Data Dependences Computation of Used and Defined Variables Computation of Reaching Definitions Variants of Program Slicing 3 Current Slicing Algorithms Slicing as a Data Flow Problem Slicing as a Graph-Reachability Problem Program Dependence Graph System Dependence Graph Computation of Summary Edges Enhancing Slicing Accuracy 4 Overview Data Structures Computation of Control Flow Information Computation of Data Flow Information Computation of Used and Defined Variables Computation of Reaching Definitions Intraprocedural Slicing Interprocedural Slicing Intermodular Slicing Support of Object-Oriented Features Modularization Module Repository Module Slicer 5 User Interface Bidirectional Links Between the Caller and the Callee Data Dependences Dynamic Types User Feedback Model-View-Controller Concept 6 Chopshop Wisconsin Progr...