Oberon Dialogs: A User Interface for End Users

Transcription

1 Oberon Dialogs: A User Interface for End Users Markus Knasmüller Institute for Computer Science (Systemsoftware) Johannes Kepler University, Altenbergerstrasse 69, A-4040 Linz knasmueller@ssw.uni-linz.ac.at Abstract This paper describes the Dialogs package which allows a user to create and use dialog viewers with buttons, check boxes, text fields and other user interface elements. Dialogs fit smoothly into the Oberon system. Existing tools can be equipped with a graphical user interface without modifications. The object-oriented nature of Dialogs allows adding new user interface items and new commands even by third party programmers and end users. 1 Introduction The original Oberon System [WiG89] has a compact textual interface. This is convenient for professional programmers, but not always for end users who prefer a graphical interface. This was especially noticed during programming lectures introducing the programming language Oberon-2 which the author gave over the last year. Graphical interfaces on modern workstations are usually a collection of interactive items such as buttons, check boxes, text fields and scroll bars allowing the user to communicate interactively with the computer. We call a panel of such items a dialog. Figure 1. A sample dialog

2 This paper describes the use and implementation of dialogs in the Oberon System. Dialogs extend the original Oberon user interface and give the user a choice between a compact textual interface (for experienced users) and a more intuitive graphical interface (for end users). A similar package for graphical user interfaces is the Gadgets system [Mar94] implemented for Oberon System 3. While the Gadgets system is more powerful (e.g. nested objects) it is also more complex and does not run under Oberon V4. The virtue of the Dialogs package is that it is extremly light-weight and smoothly fits into Oberon V4. 2 Using and Editing a Dialog Module Dialog offers commands to use, edit, store, and print a dialog. A dialog can be displayed in two modes: Dialog.Open name opens a dialog viewer and displays the dialog from file name. The user may work now with the dialog by clicking at buttons or check boxes or by typing text into a text field. He cannot modify the dialog, i.e. he cannot add or move dialog items. To do that he has to use the command Dialog.Edit. Table 1 shows the currently implemented items. Every dialog item class is defined in a separate module that exports a command Insert to insert an item of this class into the dialog containing the caret position 1. For example a button can be inserted with DialogButtons.Insert. Items can also be created using the dialog "Insert.Dlg" (see Fig. 2), which can be opened with Dialog.Open Insert.Dlg. Figure 2. Insert.Dlg 1 Clicking the left button while editing a dialog, causes a cross to appear. This cross is called caret.

3 DialogButtons DialogCheckBoxes DialogStaticTexts DialogTexts DialogGroupBoxes DialogRadioButtons DialogListBoxes A button is a small named rectangle that can be pushed with a mouse click. A check box is a rectangular button that can be in two states, on and off, toggled with a mouse click. A static text item is a text that is shown in a panel but cannot be edited. A text item is a rectangle in which the user can enter text. A group box combines all items within its rectangle into a group. Of course a group box may overlap other items. A radio button is a diamond-shaped object with a state that can be on or off. A list box displays a text of lines, that can be selected by moving the mouse up and down. DialogComboBoxes DialogSliders DialogIntegerSliders DialogLines DialogCircles A combo box is an item containing an entry field and a push button. Pushing the button causes a popup menu to appear from which the user can select an entry field. A slider consists of a rectangular area with a small bar inside. On both ends of the sliders there are buttons, containing an arrow. An integer slider is a slider displaying the actual value in a small bar inside. A line item is a graphical object. A circle may overlap other items. DialogRectangles A rectangle may overlap other elements. DialogDates DialogClocks DialogAnalogClocks A date item displays the current date. A (digital) clock displays the current time. An analog clock displays the current time. DialogGraphics Graphic items are pictures drawn with the standard Draw package. Table 1. Currently implemented items

4 Selecting an item in the list box and clicking the Set button inserts a new item in the dialog containing the caret. There are also several text items which allow the user to set the parameters of new items: If these parameters are not set, Dialogs takes some default values. The meaning of the different text items are as follows: Name the panel-wide unique name of the item. X, Y the lower left corner coordinates of the item in panel-relative coordinates. W the width of the item. H the height of the item. Cmd the command called whenever a property of the object changes. Par a string containing names of the text items or combo boxes as well as Oberon strings to be concatenated in order to form Oberon.Par.text 2. Example: To create a dialog that allows you to invoke System.Time via a button you have to execute the following steps: - Type MyDialog in the Dialog field and click the Edit Button. - Set the caret in the new viewer with a left mouse click. - Type Time in the Name field and System.Time in the Cmd field. - Select Button from the list box and click the Set Button. This produces the following dialog (see Fig. 3). Figure 3. MyDialog - Store it on a file with the command Dialog.Store from the menu of the dialog viewer. - Open it again clicking the Open button. - Every click at the Time button will now invoke the command System.Time. Items can be resized, deleted, and copied with mouse clicks. Dialogs tries to follow the Oberon conventions for mouse usage as closely as possible (e.g. MR for selecting or MR + ML for deleting). The interesting clicks are: MM (for moving an item), MM + ML (for resizing an item) and MM + MR (for opening a dialog to edit the properties of the object under the mouse pointer). A dialog item can be retrieved from a program by its name. First, a dialog panel p can be opened with DialogFrames.OpenPanel (..., p). The item with name "n" can then be retrieved with item := p.namedobject ("n"). Several procedures and methods are implemented to work with dialog items from a program [Kna94]. 2 The command cmd can assume that Oberon.Par.Text contains the texts defined through the paramter par (e. g. if par = "t1 t2 "t3"" and if there is a text item t1 containing the text "name" and also a text item t2 containing the text "text", then the command can assume that Oberon.Par.text contains the text "name text t3").

5 3 Implementation This section describes some interesting parts of the implementation. Modules and operations of the Oberon system can be studied in [Rei91]. 3.1 Dialog Items The basic objects of the framework are dialog items (e.g. check boxes or buttons). All dialog items are derived from the abstract class Dialogs.Object which has the following interface: Object = Pointer TO ObjectDesc; ObjectDesc = RECORD name: ARRAY 16 OF CHAR; (* panel wide unique name *) cmd, par: ARRAY 32 OF CHAR;(* command and parameter of the item *) x, w, y, h: LONGINT; (* lower left coordinates, width and heigth of the item *)... (* other properties *) PROCEDURE (o: Object) Draw (x, y: INTEGER; f: Display.Frame); PROCEDURE (o: Object) Print (x, y: INTEGER); PROCEDURE (o: Object) Copy (VAR dup: Object); PROCEDURE (o: Object) Load (VAR r: Files.Rider); PROCEDURE (o: Object) Store (VAR r: Files.Rider);... (* other methods *) Draw (...) and Print (...) cause the items to draw or print themselves at the given point x, y. Copy (dup) allocates a new item dup, whose properties have the same values as the source item. Load (...) reads the item from a rider, Store (...) writes it to a rider. 3.2 Dialog Panels The next higher abstraction is a dialog panel. A panel is a collection of dialog items. This collection is implemented by the class Dialogs.Panel (see Fig. 4). Panel Item Item Figure 4. Dialogs.Panel A panel calls the methods of the contained items. When a panel receives a Draw message it simply forwards the message to all its items. Even messages sent via a broadcast are forwarded to the item handlers. Additionally, a panel offers methods for the administration of a dialog, e.g. to determine the number of selected items or to align the items.

6 3.3 Dialog Frames Above Dialogs.Panel is the type DialogFrames.Frame, which is derived from Display.Frame. This is an active frame which is to be installed into a menu viewer. The most interesting field of this frame is panel, which points to an instance of the data structure described above. The most interesting procedure is Handle which has the following responsibilities: Responds to Oberon.CopyMsg and MenuViewers.ModifyMsg. Tracks the mouse cursor. If there is a corresponding item in the contained panel the item s Handle method will be called. Reacts to Dialogs.NotifyMsg (see section 3.5) (update request from the items or the panel). Broadcasts all other messages to all items of its panel. 3.4 Loading and Storing of a dialog Dialogs are made persistent by writing them to a file and reading them back as needed. To store a dialog the panel method Store (...) must be called. This method writes the name of the type for each contained item (the type can be retrieved by the Oberon operation Types.This (...)) to the file and subsequenty calls the items method Store (...), which writes the relevant item properties to the file. Relevant properties means that not all item properties have to be stored, e.g. it is not necessary to store the state of a check box. To load a dialog the panel method Load (...) must be called. It reads a type name from the file and allocates a corresponding item (with the Oberon operation Types.NewObj (...)). Now the Load (...) method of this allocated item is called to read the relevant item properties from the file. Type names can consume quite a bit of space in a file. Therefore they are stored in compressed form: with the first occurrence of a type name, it is written in full length and entered at the end of a table of type names. For further occurrences the index in the table is written instead of its full name [Mös93, p. 103]. 3.5 Multiple Views of a Dialog A dialog can be shown simultaneously in multiple views which show exactly the same dialog. If the dialog changes, all views must be updated. The concept that makes this possible is called the Model/View/Controller (MVC) concept [KrP88]. In the Dialogs package this is realized quite simply. The Model is implemented in the module Dialogs, view and controller are combined to a single class DialogFrames.Frame, i.e. each frame is one view on a dialog. The combination makes sense because view and controller always occur in pairs [Mös93, p. 113]. As described above, a dialog frame has a field panel, which references an instance of the data structure Panel described above. Introducing a new view to a dialog is nothing else than allocating a new dialog frame, with the field panel pointing to the same data structure as the first frame does. This could look like: NEW (f1); f1.panel := f.panel To have consistent views at each time, some things must be considered. To update a dialog the correct way is to modify the model (i.e. the Panel data structure), which

7 tells all its views to update themselves by broadcasting the following message: Dialogs.NotifyMsg = RECORD (Display.FrameMsg) id: INTEGER; (* 0 = restore, 1 = hide, 2 = markmenu, 3 = restore all *) obj: Object; (* defined if id = 0 or id = 1*) p: Panel; (* defined if id = 2 or id = 3 *) A NotifyMsg is sent to all viewers to draw (id = 0) or hide (id = 1) the object obj of the panel p, to mark (id = 2) the menu of the viewers containing the panel p, or to draw (id = 3) the whole panel. A menu is marked if the contents of a frame and the corresponding data structure on the file are inconsistent. Storing the frame s contents removes the mark again. 3.6 Wrapping Text Frames in Dialog Items Editable text fields are basic items of every graphical user interface. In Dialogs these text fields are implemented using the standard Oberon text frames. This allows copying text from a text frame to a dialog text field and also displaying text elements (like FoldElems or ClockElems) in such a field. The problem with this approach is that TextFrames already exist and thus cannot be made a subclass of Dialogs.Object. Furthermore this would violate the is-a relationship, for a text frame is not a dialog item. The solution was to wrap TextFrames in the new class DialogTexts.Item which is a subclass of Dialogs.Object. Wrapping means that the text frame becomes a field of class DialogTexts.Item: DialogTexts.Item = POINTER TO ItemDesc; ItemDesc = RECORD(Dialogs.ObjectDesc) f: TextFrames.Frame; Now Dialogs can handle these text items like buttons or check boxes. It can put them in the list of items and send them any messages understood by items. DialogTexts.Item object then translates these messages into TextFrames messages and forwards them to its text frame t. 4 Portability Issues Oberon Dialogs should run under all (Oberon V4) platforms (including a working Oberon-2 compiler) without any changes to the system. Oberon Dialogs was developed on a PowerMac with PowerMac Oberon. There are two known points in the package, which must be considered when compiling it on other platforms. 4.1 Module Types As described above the Oberon procedures Types.This (...) and Types.NewObj (...) are needed in the Dialogs package. Types.This (...) retrieves type descriptor with the following structure:

8 Types.TypeDesc = RECORD name: ARRAY 32 OF CHAR; module: Modules.Module; where Modules.Module has the following structure: Modules.Module = POINTER TO ModuleDescriptor; ModuleDescriptor = RECORD link: Module; name: ModuleName;... To load or store a dialog item (see section 3.4) the name of its module (module.name) and the name of its type (name) must be written to or read from the file. Unfortunately there are some OberonV4 platforms which use a different type descriptor with the following structure: Types.TypeDesc = RECORD base: ARRAY 7 OF Type; module, name: ARRAY 32 OF CHAR; The module name is directly available in the type descriptor here and need not be retrieved from the module descriptor. Of course this implies only a little modification to module Dialogs, but it must be done. 4.2 Background Bitmaps There are various items (e.g. the combo box) which respond to a mouse click by showing a new item which disappears after releasing the mouse button. Before drawing the popup the overlapped part of the screen must be saved and afterwards restored. To do so the secondary bitmap of the Oberon display could be used. In PowerMac Oberon this bitmap is only one bit deep and therefore colours would not be stored. The same problem exists on other platforms (e.g. Windows). To solve this problem the system dependent-module Bitmaps is used. If the secondary bitmap is as deep as the primary bitmap, module Bitmaps can simply save the area in the secondary bitmaps. 3 5 Conclusions The Dialogs package is an extremly light-weight package used in daily work and in different programming courses. Its main goals are platform-independence, simplicity and extensibility. With the exeption of the two mentioned points, these goals have been reached. For the future we plan the implementation of new items (e.g. Icons) and the development of graphical user interfaces for different existing Oberon applications, with non user friendly commands (e.g. Edit.Get and Edit.Set). 3 Such a module, named Bitmap.Div.Mod is part of the Dialogs package.

9 Acknowledgments I wish to thank Prof. Hanspeter Mössenböck, for the support of this project. Further thank goes to my colleagues Markus Hof, Christian Mayrhofer, Christoph Steindl and Josef Templ for their valueable input. Appendix A: How to get Dialogs Dialogs for Oberon with full source code and the report [Kna94] can be obtained via anonymous internet file transfer ftp: Oberon.ssw.uni-linz.ac.at, /pub/dialogs Appendix B: References [Kna94] M. Knasmüller Oberon Dialogs: User s Guide and Programming Interfaces Institut für Informatik (Systemsoftware), Universität Linz, Report No. 1, November 1994 [KrP88] G. Krasner, S. Pope: A Cookbook for Using the MVC User Interface Paradigm in Smalltalk Journal of Object-Oriented Programming, Aug./Sep [Mar94] J. Marais Towards End-User Objects: The Gadgets User Interface System Proceedings of the Joint Modular Languages Conference 1994 Universitätsverlag Ulm, 1994 [Mös93] H. Mössenböck Object-Oriented Programming in Oberon-2 Springer, 1993 [Rei91] M. Reiser The Oberon System; User Guide and Programmer s Manual Addison-Wesley, 1991 [WiG 89]N.Wirth, J. Gutknecht The Oberon System Software - Practice and Experience, 19, 9 (Sept 1989)