Abstract not found

Almost as long as there have been user interfaces, there have been special software systems and tools to help design and implement the user interface software. Many of these tools have demonstrated significant productivity gains for programmers, and have become important commercial products. Others have proven less successful at supporting the kinds of user interfaces people want to build. This article discusses the different kinds of user interface software tools, and investigates why some approaches have worked and others have not. Many examples of commercial and research systems are included. Finally, current research directions and open issues in the field are discussed.

Design patterns raise the abstraction level at which people design and communicate design of object-oriented software. But design patterns still leave the mechanics of their implementation to the programmer. This paper describes the architecture and implementation of a tool that automates the implementation of design patterns. The user of the tool supplies application-specific information for a given pattern, from which the tool generates all the pattern-prescribed code automatically. The tool has a distributed architecture that lends itself to implementation with off-the-shelf components. 1

Numerous classes, complex inheritance and containment hierarchies, and diverse patterns of dynamic interaction all contribute to difficulties in understanding, reusing, debugging, and tuning large object-oriented systems. To help overcome these difficulties, we introduce novel views of the behavior of object-oriented systems and an architecture for creating and animating these views. We describe platform-independent techniques for instrumenting object-oriented programs, a language-independent protocol for monitoring their execution, and a structure for decoupling the execution of a subject program from its visualization. Case studies involving tuning and debugging of real systems are presented to demonstrate the benefits of visualization. We believe that visualization will prove to be a valuable tool for object-oriented software development.

The Lapidary interface design tool is a demonstrational system that allows the graphics and run-time behaviors that go inside an application window to be specified pictorially. In particular, Lapidary allows the designer to draw example pictures of application-specific graphical objects that the end user will manipulate (such as boxes and arrows, or elements of a list), the feedback that shows which objects are selected (such as small boxes on the sides and corners of an object), and the dynamic feedback objects (such as hair-line boxes to show where an object is being dragged). The run-time behavior of all these objects can be specified in a straightforward way using constraints, demonstration, and dialog boxes that allow the designer to provide abstract descriptions of the interactive response to the input devices. Lapidary generalizes from these specific example pictures and behaviors to create prototype objects and behaviors from which instances can be made at run-time. A novel fea...

Conventional windowing environments provide separate classes of objects for user interface components, or "widgets," and graphical objects. Widgets negotiate layout and can be resized as rectangles, while graphics may be shared (not just strictly hierarchical) transformed, transparent, and overlaid. This presents a major obstacle to applications like user interface builders and compound document editors where the manipulated objects need to behave both like graphics and widgets. Fresco[1] blends graphics and widgets into a single class of objects.We have an implementation of Fresco and an editor called Fdraw that allows graphical objects to be composed like widgets and widgets to be transformed and shared like graphics. Performance measurements of Fdraw show that sharing reduces memory usage without slowing down redisplay. KEYWORDS: User interface toolkit, object-oriented graphics, structured graphics. 1 INTRODUCTION As user interfaces evolve toward more realistic representations of ...

Abstract not found

The Lapidary interface design tool allows the graphics and run-time behaviors that go inside an application window, as well as the graphics and behaviors that go around the application window, such as menus and scroll bars, to be specified pictorially. In particular, Lapidary allows the designer to draw pictures of application-specific graphical objects that the end user will manipulate (such as boxes and arrows, or elements of a list), the feedback that shows which objects are selected (such as small boxes on the sides and corners of an object), and the dynamic feedback objects (such as hair-line boxes to show where an object is being dragged). The run-time behavior of all these objects can be specified in a straightforward way using constraints and dialog boxes that allow the designer to provide abstract descriptions of the interactive response to the input devices. Lapidary also generalizes from the specific example pictures to allow the graphics and behaviors to be specified by demonstration. Finally, Lapidary supports the construction and use of "widgets" (sometimes called interaction techniques or gadgets) such as menus, scroll bars, buttons and icons. Thus Lapidary allows all pictorial aspects of an application to be specified graphically.

sent us e-mail that attempted to show “how patterns, classical algorithms and data structures, and [work like Andrei’s] seem to dovetail in a way that offers benefits to people working in each of those fields. ” The details of that message and the ensuing thread are pretty interesting. I hope Scott sees fit to publish it someday. What really struck me, though, was Andrei’s work, 1 both for its relationship to code generation (something I’ve dabbled in 2,3) and for its potential impact on pattern application. Nay, I found Andrei’s stuff so intriguing and germane that I immediately felt an urge to give it a column—or two, as it turns out. But it would be impolite to share these goodies with you apart from their inventor, and I couldn’t do them justice anyway. So I am both honored and relieved to co-author these columns with Andrei. Consider them his; I’m just kibitzing. Talkin ’ ’bout code generation The idea of a tool producing code automatically enthralls many developers, for good reason: Why crank out code yourself when a machine can do it for you? The more code you don’t write, the easier your life gets, and the fewer bugs you’ll get blamed for. That’s not to say generated code is always perfect—generators are software too, you know. But owing to their mission as system tools, there’s incentive to lavish lots of time and effort on getting them right. Generators and the code they generate are thus far less likely to harbor