|
Abstract : |
ABSTRACT toolkits today require the programmer to specify call-backs Conventional toolkits today require the programmer to at- for almost every widget in the interface, and some widgets tach call-back procedures to most buttons, scroll bars, even take more than one call-back. For example, the slider menu items, and other widgets in the interface. These widget in Motif has two call-backs, one for when the in-procedures are called by the system when the user operates dicator is dragged and one for when it is released. the widget in order to notify the application of the user?s actions. Unfortunately, real interfaces contain hundreds or thousands of widgets, and therefore many call-back procedures, most of which perform trivial tasks, resulting in a maintenance nightmare. This paper describes a system that allows the majority of these procedures to be eliminated. The user interface designer can specify by demonstration many of the desired actions and connections among the widgets, so call-backs are only needed for the A typical user interface for a moderately complex program will contain hundreds or even thousands of widgets. For example, the VUIT program from DEC uses over 2500 widgets. This means that the programmer must provide many call-back procedures. To add to the complexity, each type of widget may have its own protocol for what parameters are passed to the call-back procedures, and how the procedures access data from the widget. most significant application actions. In addition, the callbacks that remain are completely insulated from the widgets, so that the application code is better separated from the user interface. The use of all of these call-backs means that the user inter-face code and the application code are not well separated or modularized. In particular: ? The call-backs closely tie the application code to a par-KEYWORDS: Call-Back, |
