Subject: On API for windowing systems

From: [email-masked] (Koreaki Fujimura)
Date: Fri, 11 Sep 92 21:45:17 JST

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)