From fujimura@etl.go.jp Fri Sep 11 14:44:12 1992 Received: from [192.31.197.33] by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA07293; Fri, 11 Sep 92 14:44:12 +0200 Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (5.67+1.6W/2.7W) id AA07909; Fri, 11 Sep 92 21:44:29 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA19164; Fri, 11 Sep 92 21:45:17 JST Date: Fri, 11 Sep 92 21:45:17 JST From: fujimura@etl.go.jp (Koreaki Fujimura) Return-Path: Message-Id: <9209111245.AA19164@etlpom.etl.go.jp> To: sc24@dkuug.dk Subject: On API for windowing systems X-Charset: ASCII X-Char-Esc: 29 Title: Comments on the API for widowing systems in SC24 Source: Windowing Study Group in the Japanese National Body (directed by Tokio Okazaki, IBM-Japan) Status: For Information at the SC24 October meeting Date: 1992-09-11 ---------------------------------------------------------------- We have reviewed the comments attached to the voting on Document JTC 1 N 1533, Proposal for a New Work Item on API for Windowing Systems. We admit that the description of the project was insufficient and have tried to make it sufficient. We have also studied about the feasibility of handling of windowing functionality within graphics under present circumstances and become to think that standardization of an API for windowing systems which we once proposed should not be done as a SC24 project in spite of some national body's comments. We think the best way to present the result of our study is in the form of annotation to the NP proposal as follows. -------------- JTC 1 N 1533 Proposal annotated -------------------- PURPOSE AND JUSTIFICATION The Japanese National Body carefully studied the TSG-1 report, to determine at least three NWI proposals were required, one enclosed herewith and the others proposed separately. 1. Environment of Windowing System Since the introduction of the GUI (Graphical User Interface), more and more attention has been paid to the importance of the user interface, i.e. the means through which the application program communicates with the human user. Adoption of the GUI has been promoted, and enabled the human user to accept markedly improved friendliness, operability and comprehensibility. On the other hand, development of applications with the GUI was apt to be burdensome. Controlling the user interaction with the GUI required more sophisticated technique than with the traditional character-based user interface. Eventually, windowing systems were developed, one after another, to relieve the burden of developing applications using the GUI. AS a result, today, although many individual windowing systems are available, these products have no consistency with one another. Under these circumstances, the standardization should be endeavored to bring forth the application program portability and to reduce the conversion workload. | NOTE) At that time when we studied and proposed this NP proposal, | there were many individual windowing systems whose APIs had no consistency | and the standardization of API had been necessary, as mentioned above. | | But in recent years the circumstance has been changing. | | - Some windowing system attempts to execute application programs of | other windowing system. For example, MS Windows applications can be | executed in OS/2 2.0 environment. | | - USL MoOLIT toolkit that is one component of SVR4.2 supports both Open | Look and Motif look&feels. This is an implementation of look&feel | independency. | | - Some ISV(independent software vendor)s provide GUI construction | tools, such as OpenInterface, that can cover some different windowing | systems. They enables programmers to develop GUI part of applications | without any attention to the difference between windowing systems. 2. Structure of Windowing Systems From the interface point of view, windowing systems will be assumed to have two aspects. One is the Application Program Interface (API), and the other is the Look And Feel (LAF). Only the former will be the target of this proposal. To clarify what the API is, it will be worthwhile to review, in more detail, the structure of windowing systems, whose layers are illustrated in Figure 1. +-------------+ | Application | +-----+-------+ | ========================= API | Dialogue | +------------------+ +--------------+ | Presentation |-- LAF --| Human user | +------------------+ +--------------+ | Window | +------------------+ | Physical device | +------------------+ Figure 1. Structure of Windowing Systems - The dialogue layer handles, at the logical level, the interaction between the human user and the application program. | NOTE) This layer provides such a facility as User Interface Management | System (UIMS), that had been once discussed in IEEE1201.3. - The presentation layer maps the display actions into the abstract display device, and also it maps the input events, from the abstract pointing device or the abstract keyboard, into the input operations. | NOTE) This layer corresponds to the GUI toolkit such as Motif and Open Look | Toolkit. We think the Uniform API(UAPI) discussed in IEEE1201.1 should | be the interface provided by this layer. And IEEE1201.2 discussing | the drivability seems to be intend to standardize the look&feel provided by | this layer. The purpose of our NP proposal is to standardize the API of | this layer. - The window layer relates the abstract devices to the corresponding physical devices which are on the physical device layer, so that the upper layer may behave independently of the physical devices. - The physical device layer is the one on which physical devices, such as a mouse, a bit map display and a keyboard, are mapped. 3. API of Windowing Systems The following two items are the major concerns from the application program portability point of view. - API (Application Program Inteface) : Interface between the application program and the dialogue layer - LAF (Look And Feel) : Interface between the presentation layer and the human user As for the LAF, it defines the interaction between the abstract device and the human user. Today, there are varieties of windowing systems, of which users will make selection according to their tastes. No windowing system seems to be dominant as yet. Therefore, this proposal intends to deal with not the LAF but just the API portion. The standardization of the API will have the application program portability be increased and the required effort for conversion be decreased. | NOTE) We have investigated the would-be API for windowing | systems in detail after proposing the NP. But we have finally concluded | that our technology level is so immature that we cannot define the | standard of the API in reasonable time frame. 4. Conclusion An API, whose level of abstraction is higher than that of conventional windowing systems should be defined as the standard. Then programmers can produce applications portable over different windowing systems, only by following this API, by which the mapping of interfaces to various windowing systems will be achieved. Consequently, the application program portability will be drastically enhanced and the conversion workload will be minimized. | NOTE) We become to think that standardization of an API for windowing | systems which we once proposed should not be done as a SC24 project | because | | - the recent industrial practice lessen the need for standardization and | | - our original proposal is to define a presentation-independent | windowing systems interface which is very far from the area of | work for SC24. 5. Program of work 1. '91/12 Working Paper 2. '92/07 Working Paper 3. '92/12 CD 4. '93/07 Revised CD 5. '93/12 DIS (END)