Personality Neutral Window Management Subsystem

The present invention relates to computer graphics, and more particularly to a window management system which supports the simultaneous operation of a plurality of different graphical user interfaces on a single display.

The past decade was a revolutionary time in computing. The advent and proliferation of personal computers has transformed the computer environment from one of large mainframe computer systems which was highly centralized and tightly controlled, to a network of interconnected personal computers and workstations which are often widely distributed yet easily accessible via computer networking.

Concomitant with this change in computer environments is the significant change in the way a user interfaces with the computer. In the past, the display of information on the screen was primarily alphanumeric. In addition, commands such as operating system commands (e.g., DOS commands) were input through a keyboard to control the computer. These commands were often archaic and difficult for users to understand and work with, particularly nontechnical users, without first investing significant amounts of time to learn the commands.

A revolution in computing occurred when the graphical user interface (GUI) was introduced. This user interface is displayed on the monitor to the user, and as its name suggests, is primarily graphics oriented. Rather than typing commands into the computer via a command line, the GUI allows users to control the operation of the computer via the manipulation of icons and dialog boxes displayed on the monitor within a region referred to as a "window". Each icon represents a functional task which the user can select for execution by simply clicking on the icon. The term "window" is well known in the art, and is generally a rectangular region on a computer display, which receives user inputs and displays output.

GUIs generally include a window management system which enables a user to establish, destroy, minimize and maximize windows on the display screen. The window management system, places control bars (e.g., a scroll bar) and title bars, and controls the Z-ordering and clipping of the various windows on the display screen. In response to a request from an application program, the window manager establishes a window and allocates a region of the display screen for in which the window the application program can use to present information on the display.

To draw within a window, GUIs generally also include a graphics controller which draws lines, circles, points, which controls how the data to be displayed is presented on the display. Oftentimes, the display of the computer system having a plurality of windows is referred to as a "desktop" with each window seemingly representing a piece of paper lying on the desktop.

The first personal computer to gain widespread commercial acceptance for the GUI was the Macintosh.RTM. personal computer by Apple Computer, Inc. Based upon the popularity of the GUI for the Macintosh and its obvious advantages such as its user friendly nature, GUIs quickly gained widespread acceptance.

Software developers for IBM compatible personal computers also introduced GUI products. The first widely used GUI for IBM compatible personal computers (hereinafter "PC") was WINDOWS.TM. developed by Microsoft Corporation (MS). WINDOWS runs on top of the DOS operating system and provides a "shell" (i.e., an interface) between application program and the operating system. The WINDOWS GUI allows a user to control the execution of application program(s) by pointing and clicking with a pointer device (e.g., a mouse or trackball) on the screen. Due to the market acceptance of the WINDOWS GUI, application program vendors moved quickly to introduce products into the market which operated with the WINDOWS GUI.

IBM also introduced a new operating system known as OS/2.RTM. which included its own GUI referred to as PRESENTATION MANAGER.TM.. In order to use OS/2 and its GUI PRESENTATION MANAGER, application program vendors had to update their products to operate with PRESENTATION MANAGER so the application program could display information on the screen.

As different GUIs entered the market, compatibility became a problem since each GUI had its own application programming interface (API) with particular functions an application program would call to interface with the GUI. API calls generally fall into two categories 1) windows related, and 2) graphics related. With a GUI, the application program no longer has direct control over the display; the application simply passes information and commands to the GUI via API calls, and the GUI issues the necessary commands to a graphics engine to display the information on the screen. Therefore, an application program written to operate with a particular GUI was limited to operating with only that GUI.

As an example, if an application program was written to execute with the OS/2 PRESENTATION MANAGER graphical user interface, it could not be executed on a computer running the WINDOWS graphical user interface since the API calls were different. Hence, application program vendors have had to supply different versions of their application program for each GUI. Thus users have to select between the DOS, WINDOWS or PRESENTATION MANAGER compatible version of the same application program.

In an attempt to resolve this problem, IBM introduced a version of OS/2 which allowed applications written for GUIs other than PRESENTATION MANAGER to execute using the PRESENTATION MANAGER graphical user interface. This version was designated OS/2 Version 2.1 Special Edition and it allowed an application program, such as the word processing package Microsoft WORD 6.0 for WINDOWS, to be run on the PRESENTATION MANAGER GUI. This version of OS/2 also included the capability that multiple windows could be displayed on the screen simultaneously, wherein each window may contain information from applications written for different GUIs.

A problem with this earlier IBM approach was that it required that WINDOWS be loaded and resident in RAM. Therefore, in order to have the flexibility to run non-OS/2 based applications using the PRESENTATION MANAGER GUI, the user had to execute both WINDOWS and OS/2 PRESENTATION MANAGER. This was a costly solution since it required that the user have both OS/2 and WINDOWS resident and operating on the computer. In addition, this approach required a large amount of code. If a user was running several windows on the screen, each window used its own dedicated window manager to control the window.

European Patent Application, EP 0 597 395 A1, published May 18, 1994 discloses a system which allows an application program written for a certain GUI (e.g., PRESENTATION MANAGER), to be run on a system using a different GUI. The system uses a mapping layer to transform the API calls from PRESENTATION MANAGER running in one CPU, to a format compatible with the GUI operating in another CPU. This system relates to displaying information from an application program running in a remote CPU having a certain GUI, on a CPU running a different GUI which interconnected over a network. The system does not allow the "porting" of application programs between various types of computer systems and their different GUIs since it requires two CPUs. Another problem with this system is that mapping layer of code adds a layer of complexity which slows the system down and adds redundancy to the code.

It would therefore, be desirable to provide window management services routine which allows applications having different GUIs to run simultaneously on the same desktop.

An object of the present invention is to allow application programs written for different graphical user interfaces to be executed together on a single desktop.

Another object of the present invention is to provide a personality neutral common window management system capable of interfacing with application programs written for various graphical user interfaces.

Yet another object of the present invention is to provide a common graphical user interface which allows application programs written for other graphical user interfaces, to be imported and seamlessly executed on a desktop controlled by the common graphical programming interface.

Briefly, the present invention is a window management system resident in a computer operating system which provides a generic windowing interface for application programs written to operate with various specific graphical user interfaces. The window management system includes a common graphical user interface (CGUI) which receives window related application programming interface (API) calls from the application programs, and transforms the various types of API calls native to a particular graphical user interface, into a generic format compatible with a personality neutral common windowing format. The personality neutral calls are then passed from the CGUI to a personality neutral event/window management server which services the calls, and controls the creation, deletion and modification of the various windows on the display.

The CGUI also includes an event/message server which routes event information and messages between the personality neutral event/window management server and each of the GUIs and application programs.

To handle the API calls associated with the various types of graphical user interfaces supported by the CGUI, the CGUI includes a plurality of GUI specific front-end interfaces, each associated with a particular type of GUI, such as OS/2 PRESENTATION MANAGER, MS WINDOWS, X-WINDOWS.TM., etc., and which each receive API function calls from application programs written for that particular type of GUI. Each windowing front-end interface receives the API call from a corresponding GUI and transforms the GUI specific personality neutral API calls.

The CGUI also includes a plurality of windowing back-end interfaces each of the windowing back-end interfaces associated with a corresponding one of the plurality of GUI specific windowing front-end interfaces. Each windowing back-end interface converts the call received from the windowing front-end interface into a format compatible with the common event/window management server and passes the transformed calls onto the common event/window management server. The common event/window management server is personality neutral since the application programming interface between it and each of the plurality of windowing back-end interfaces is the same.

The common event/window management server is a special trusted application which performs window management services such as establishing a window, destroying a window, window clipping, Z-ordering, and other relatively low level windowing tasks.

The window manager system of the present invention is a personality neutral windowing interface since it allows application programs written for a first graphical user interface to operate on a computer executing a second different graphical user interface. As an example, the PRESENTATION MANAGER GUI which runs on top of the OS/2 operating system may be modified to incorporate the personality neutral windowing management system of the present invention such the resultant modified GUI can display information for various application programs written for other GUIs such as WINDOWS, X-WINDOWS, Macintosh or other known graphical user interfaces.

The present invention allows a single window manager to create and remove windows displayed on the desktop, along with the control of those windows including clipping, Z-ordering, dragging-and-dropping, and hiding and showing windows as required in response to user commands.

An advantage of the present invention is that users can now use a single graphical user interface and operating system to execute application programs written for different graphical user interfaces.

In addition, the architecture of the window management server reduces the code required to implement the personality neutral window management server and enhances reuse of the code.

These and other objects, features and advantages of the present invention will become more apparent in light of the following detailed description of a preferred embodiment thereof, as illustrated in the accompanying drawings.

FIG. 1 is an pictorial illustration of multiple windows being displayed on a display using a single graphical user interface;

FIG. 2 is a block diagram of a personal computer system; and

FIG. 3 is a functional block diagram of a personality neutral common window management system.

Referring now to FIG. 1, a personal computer system 20 includes a central processing unit (CPU) 22 (e.g., PENTIUM.TM., POWERPC.TM., etc. . . ), ROM 24, RAM 26, and an I/O adapter 28 which are all interconnected via a system bus 30. The system also includes a keyboard 32, trackball 34, mouse 36, and a speaker 38 which are interconnected to the bus 30 using well-known techniques via a user interface adapter 40. To present information to the user, the system includes a display adapter 42 (e.g., a super VGA card) which receives commands and data to be displayed via the bus and displays the data on a monitor 44 such as a CRT or a flat panel display. The system also includes a communications adapter 46 which allows the system to be interconnected to a local area network (LAN) or a wide area network (WAN).

The computer 20 executes a software operating system (e.g., OS/2) which in a well known manner provides centralized resource management for the CPU, memory, mass-storage devices, I/O devices such as the keyboard, display and mouse and the communication interfaces. The operating system generally includes a kernal, device driver routines and dynamic link libraries which the application programs indirectly interact with through a graphical user interface. The operating system may for example be provided as a multi-tasking operating system which allows several applications to be displayed simultaneously on the monitor within their own window.

The present invention is directed to a computer system executing a single graphical user interface and operating system capable of executing application programs written for different graphical user interfaces. This allows user written for various graphical user interfaces between different computer systems. FIG. 2, for example, illustrates a screen 49 viewed on the monitor 44 (FIG. 1). Screen 49 includes two windows 50,52. The windows 50, 52 represent information from different application programs being executed by computer system 20 (FIG. 1). For example, the application program running within window 50 may be a word processing application written for an MS WINDOWS GUI, while the application program running within window 52 may be a spreadsheet application written for a UNIX.RTM. based X-WINDOWS GUI. Of course, many other applications are capable of being run in the windows 50, 52, and those of ordinary skill in the art will recognize of course that more than two windows may be simultaneously displayed on screen 49.

Referring now to FIG. 3, a common windowing management system 80 which controls the windows (e.g., 50, 52 FIG. 2) displayed on the display 44 is adapted to receive windowing related API calls from a plurality of different application programs 82a-82N generally denoted 82 which are being concurrently executed by the computer system 20.

In this particular example, the application programs 82 include a first application program 82a written to cooperate with the OS/2 PRESENTATION MANAGER GUI, a second application program 82b written to cooperate with the MS WINDOWS 3.1 based GUI and a third application program 82N written to cooperate with the X-WINDOWS GUI. Typical windowing API calls include but are not limited to calls to create windows, delete windows and control the Z-ordering and clipping of the windows presented on the display.

Each of the windowing related API calls from application programs 82 are input to a common graphical user interface (CGUI) 86 which includes a plurality of personality specific GUI routines 88a-88N generally denoted 88. Each of the personality specific GUI routines 88 interface with a particular one of the above identified GUIs. Thus, CGUI 86 supports, for example, the OS2 PRESENTATION MANAGER GUI, the MS WINDOWS GUI and the X-WINDOWS GUI.

CGUI 86 may also support Macintosh and other known GUIs. The particular number of personality specific GUI routines 88 included in CGUI 86 depends upon a variety of factors including but not limited to the number of different application programs 82 which the CGUI is capable of concurrently executing. For example, if the CGUI 86 was capable of executing application programs written for five different types of GUIs, CGUI 86 would include five personality specific GUI routines 88 to translate GUI API calls from a GUI specific format to a format compatible with the personality neutral windowing system of the present invention.

Taking GUI routine 88a as representative of GUI routines 88b-88N, personality specific GUI routine 88a includes a GUI specific windowing front-end 92a which receives the windowing related API calls from a particular one of the application program and decodes the personality specific windowing API calls to determine the specific lower level calls necessary to perform the windowing tasks associated with the particular call. The calls are then passed to a windowing back-end 96a which translates the GUI specific commands into personality neutral windowing API calls the personality neutral windowing calls. The personality neutral windowing calls are subsequently provided over a data path 99a to a common event/window management server 100. Thus, each of the personality specific GUI modules 88a-88N receives personality specific GUI command from a respective one of the application programs 82a-82N and provides at a corresponding one of the data paths 99a-99N a personality neutral GUI command.

Since the windowing commands sent from each of the personality specific GUI routines 88 to the common event/window management server 100 are independent of the GUI for which the application program was written, the interface between each of the GUI windowing back ends 96a-96N is the same. The interface between the windowing back-ends 96 and the common event/window management server 100 is thus referred to as personality neutral and therefore a single, common event/window management server 100 can support all the GUIs.

Prior art techniques, on the other hand, use multiple window management servers each of which is dedicated to support one of the GUIs which the system can run.

The personality neutral event/window management server 100 of the present invention, however, maintains all system window definitions in a single location and supports windowing in a manner which is transparent to all the application programs executing on the computer system 20.

To control the windows, the common event/windowing management server 100 transmits commands to a microkernel 101. Microkernel 101 includes a display device driver (not shown) which issues the appropriate display dependent commands to control the windows (e.g., 50,52 in FIG. 2) displayed on the display.

The common event/window management server 100 is a special application which controls the windows on the desktop (i.e., controls the windows displayed on the screen) and establishes, modifies and deletes windows as a function of the API calls from the various application programs 82. As an example, the common event/window management server 100 supports well known windowing tasks such as clipboard, data exchange, drag-and-drop, window sizing, launching applications and hiding and showing windows (e.g., window clipping and Z-ordering).

The common event/window management server 100 manages first level windows for main frame buffers, overlay planes, and video masking planes (i.e., a black hole manager). The window manager 100 also specifies the input focus policy and controls the default window decorations. Generally, it is preferred that the window decorations (e.g., title bars, command lines, etc. . . ) will be provided in the native style of the application's GUI personality. Thus, even for a WINDOWS application running on the OS/2 PRESENTATION MANAGER, the window will have decorations analogous to a WINDOWS native execution of the application. In the case of an application that does not have a "native" GUI format, the desktop will provide decorations in its usual style.

The common windowing system of the present invention preferably uses an event driven message based input/output architecture to connect the user interface to the PRESENTATION MANAGER application. In such a system, events such as user keyboard inputs and mouse clicks are translated by the operating system into messages which are sent to the appropriate one of the application programs 82. Each message generally includes: 1) a handle to identify the window the message is associated with, 2) the message type, and 3) the data of the message. If the message contains a large mount of data it may contain a pointer to the message data in memory. Examples of windowing related messages for an OS/2 based operating system include WM.sub.-- CREATE, WM.sub.-- SIZE and WM.sub.-- CHAR.

To translate events into messages, event inputs from the keyboard 32 and mouse 36 are input to a microkernel 101 which includes mouse and keyboard drivers. The mouse and keyboard drivers each route event information to the common event/window management server 100. The server 100 determines in which window the event occurred (e.g., which window was active) and the position of the mouse pointer within the window when the mouse button was pressed and released (i.e., "clicked").

The server 100 then generates a message containing the window handle which directs the message to the personality specific GUI routines 88 associated with the window. Each of the personality specific GUI routines 82 includes a message queue. The personality specific GUI routines 88 place the message generated by server 100 in the message queue. The message queue is polled in a regular sequence by the application programs 82 accessing that GUI routine. Window procedures within the application programs act upon the messages and generate the necessary windowing API calls in response to the messages.

Since each GUI will generally deal with messages in a slightly different manner (i.e., personality specific), each of the personality specific GUI routines 88a-88N includes a GUI specific event/messaging front-end interface 102a-102N generally denoted 102 that provides the message data in the format compatible with its associated GUI.

Each event/messaging front-end interface 102 is preferably provided as a dynamically linked library routine (instantiated for each message queue created by an application), implemented in two layers, with an intervening application message queue. The back-end 103a performs common functions such as queue management and message routing. The queue may either include separate queues for events (inputs to the system) and messages (passed by other applications and components) in each application, or a combined application queue. If a combined application queue is used it is necessary to implement event/message priority levels to enable messages to be processed before the events, in the common PMWIN fashion.

The event/messaging front-end interface 102 and back-end form an interface which allows existing OS/2 PRESENTATION MANAGER applications, which use fixed length, pass-by-value messages to communicate with the common event/message management server 100 which preferably uses variable-length, pass-by-packet (or pass-by-reference) messages.

The interface between the CGUI 86 and the common event/window management server 100 is preferably selected to have a high degree of commonality with existing GUIs such as PRESENTATION MANAGER, WINDOWS, X-WINDOWS and Macintosh. This ensures that GUI developers who wish to modify their GUI to work with the common event/window management server 100 will be able to retain some of the code from the their current GUI.

In an alternate embodiment, the invention may be implemented as a computer program product for use with a computer system. Such implementation may comprise a series of computer instructions either fixed on a tangible medium, such as a computer readable media, e.g. diskette 142, CD-ROM 147, ROM 24, or fixed disk 152 (FIG. 1), or transmittable to a computer system, via a modem or other interface device, such as network controller 110 connected to the network 120 over a medium 121, which can be either a tangible medium, including but not limited to optical or analog communications lines, or use wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention. Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software; preloaded with a computer system, e.g., on system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web.

Although the present invention has been shown and described with respect to a best mode embodiment thereof, it should be understood by those skilled in the art that various other changes, omissions and additions to the form and detail thereof, may be made therein without departing from the spirit and scope of the invention.