Object-oriented viewing framework having view grouping

Description Submit all comments and votes

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as appears in the Patent and Trademark Office.

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

This patent application is related to the patent application entitled Object Oriented Area System, Ser. No. 08/113,442, now U.S. Pat. No. 5,428,744, entitled Object-Oriented System for Building a Graphic image on a Display by Richard Daniel Webb et al. filed Jun. 20, 1993, and assigned to Taligent, the disclosure of which is hereby incorporated by reference. This application is related to U.S. patent application Ser. No. 08/161,894, entitled Object-Oriented Display System.

FIELD OF THE INVENTION

This invention generally relates to improvements in computer systems and, more particularly, to operating system software for managing drawing areas, called views, inside of a window display area in a graphic user interface.

BACKGROUND OF THE INVENTION

One of the most important aspects of a modern computing system is the interface between the human user and the machine. The earliest and most popular type of interface was text based; a user communicated with the machine by typing text characters on a keyboard and the machine communicated with the user by displaying text characters on a display screen. More recently, graphic user interfaces have become popular where the machine communicates with a user by displaying graphics, including text and pictures, on a display screen and the user communicates with the machine both by typing in textual commands and by manipulating the displayed pictures with a pointing device, such as a mouse.

Many modern computer systems operate with a graphic user interface called a window environment. In a typical window environment, the graphical display portrayed on the display screen is arranged to resemble the surface of an electronic "desktop" and each application program running on the computer is represented as one or more electronic "paper sheets" displayed in rectangular regions of the screen called "windows".

Each window region generally displays information which is generated by the associated application program and there may be several window regions simultaneously present on the desktop, each representing information generated by a different application program. An application program presents information to the user through each window by drawing or "painting" images, graphics or text within the window region. The user, in turn, communicates with the application by "pointing at" objects in the window region with a cursor which is controlled by a pointing device and manipulating or moving the objects and also by typing information into the keyboard. The window regions may also be moved around on the display screen and changed in size and appearance so that the user can arrange the desktop in a convenient manner.

Each of the window regions also typically includes a number of standard graphical objects such as sizing boxes, buttons and scroll bars. These features represent user interface devices that the user can point at with the cursor to select and manipulate. When the devices are selected or manipulated, the underlying application program is informed, via the window system, that the control has been manipulated by the user.

In general, the window environment described above is part of the computer operating system. The operating system also typically includes a collection of utility programs that enable the computer system to perform basic operations, such as storing and retrieving information on a disc memory and performing file operations including the creation, naming and renaming of files and, in some cases, performing diagnostic operations in order to discover or recover from malfunctions.

The last part of the computing system is the "application program" which interacts with the operating system to provide much higher level functionality, perform a specific task and provide a direct interface with the user. The application program typically makes use of operating system functions by sending out series of task commands to the operating system which then performs a requested task, for example, the application program may request that the operating system store particular information on the computer disc memory or display information on the video display.

FIG. 1 is a schematic illustration of a typical prior art computer system utilizing both an application program and an operating system. The computer system is schematically represented by box 100, the application is represented by box 102 and the operating system by box 106. The previously-described interaction between the application program 102 and the operating system 106 is illustrated schematically by arrow 104. This dual program system is used on many types of computer systems ranging from main frames to personal computers.

The method for handling drawing to screen displays varies from computer to computer and, in this regard, FIG. 1 represents a prior art personal computer system. In order to provide drawing to screen displays, application program 102 generally stores information to be displayed (the storing operation is shown schematically by arrow 108) into a screen buffer 110. Under control of various hardware and software in the system the contents of the screen buffer 110 are read out of the buffer and provided, as indicated schematically by arrow 114, to a display adapter 112. The display adapter 112 contains hardware and software (sometimes in the form of firmware) which converts the information in screen buffer 110 to a form which can be used to drive the display monitor 118 which is connected to display adapter 112 by cable 116.

The prior art configuration shown in FIG. 1 generally works well in a system where a single application program with a single thread of execution 102 is running at any given time. This simple system works properly because the single application program thread 102 can write information into any area of the entire screen buffer area 110 without causing a display problem. However, if the configuration shown in FIG. 1 is used in a computer system where more than one application program, or more than one thread of execution in that application program 102 can be operational at the same time (for example, a "multitasking" computer system) display problems can arise. More particularly, if each thread in each application program has access to the entire screen buffer 110, in the absence of some direct communication between threads and applications, one thread may overwrite a portion of the screen buffer which is being used by another thread, thereby causing the display generated by one thread to be overwritten by the display generated by the other thread.

Accordingly, mechanisms were developed to coordinate the operation of the applications as well as the threads of execution within the applications to ensure that each application thread was confined to only a portion of the screen buffer thereby separating the other displays. This coordination became complicated in systems where multiple "windows" with multiple threads drawing to those windows were allowed. The problem was divided into two pieces: Managing the windows and their display area (application programs) and managing the threads of execution within those applictions. The Window Manager handles coordination between applictions and their windows. The View System handles coordination of threads within the applications and their window(s). Each window is subdivided in a hierarchy of drawing areas called "views" which are associated with specific threads of execution within a given application program.

When the application window is arranged so that views appear to "overlap", a view which appears in the window in "front" of another view covers and obscures part of the underlying view. Thus, except for the foremost view, only part of the underlying views may be drawn on the screen and be "visible" at any given time. Further, because the view can be moved or resized by the user, the portion of each view which is visible changes as other view are added, removed, moved or resized. Thus, the portion of the window which is assigned to each thread also changes as views from other threads are added, removed, moved or resized.

In order to efficiently manage the changes to the window necessary to accommodate rapid screen changes caused by moving or resizing views, the prior art computer arrangement shown in FIG. 1 was modified as shown in FIG. 2. In this new arrangement computer system 200 is controlled by one or more application programs, comprised of one or more threads of execution, of which threads 202 and 216 are shown, and which may be running simultaneously in the computer system. Each of the threads interfaces with the operating system 204 as illustrated schematically by arrows 206 and 220. However, in order to display information on the display screen, application threads 202 and 216 send display information to a central View System 218 located in the application program 204. The view system 218, in turn, interfaces directly with the screen buffer 210 as illustrated schematically by arrow 208. The contents of screen buffer 210 are provided, as indicated by arrow 212, to a display adapter 214 which is connected by a cable 222 to a display monitor 224.

In such a system, the view system 218 is generally responsible for maintaining all of the display contents that the user sees within a window during operation of the application programs. Since the view system 218 is in communication with all the treads within an application, it can coordinate between threads to insure that view displays do not overlap. Consequently, it is generally the task of the view system to keep track of the location and size of the view and the view areas which must be drawn and redrawn as views and windows are moved.

The view system 218 receives display requests from each of the application threads 202 and 216. However, since only the view system 218 interfaces with the screen buffer 210, it can allocate respective areas of the screen buffer 210 for each application and insure that no thread erroneously overwrites the display generated by another thread. There are a number of different window environments commercially available which utilize the arrangement illustrated in FIG. 2. These include the X/Window Operating environment, the WINDOWS, graphical user interface developed by the Microsoft Corporation and the OS/2 Presentation Manager, developed by the International Business Machines Corporation.

Each of these window environments has its own internal software architecture, but the architectures can all be classified by using a multi-layer model similar to the multi-layer models used to described computer network software. A typical multi-layer model includes the following layers:

User Interface

Winow Manager

Resource Control and Communication

Component Driver Software

Computer Hardware

where the term "window environment" refers to all of the above layers taken together.

The lowest or computer hardware level includes the basic computer and associated input and output devices including display monitors, keyboards, pointing devices, such as mice or trackballs, and other standard components, including printers and disc drives. The next or "component driver software" level consists of device-dependent software that generates the commands and signals necessary to operate the various hardware components. The resource control and communication layer interfaces with the component drivers and includes software routines which allocate resources, communicate between applications and multiplex communications generated by the higher layers to the underlying layers. The view system handles the user interface to basic drawing operations, such as moving and resizing views, activating or inactivating views and redrawing and repainting views. The final user interface layer provides high level facilities that implement the various controls (buttons, sliders, boxes and other controls) that application programs use to develop a complete user interface.

Although the arrangement shown in FIG. 2 solves the display screen interference problem, it suffers from the drawback that the view system 218 must process the screen display requests generated by all of the application threads. Since the requests can only be processed serially, the requests are queued for presentation to the view system before each request is processed to generate a display on terminal 224. In a display where many views are present simultaneously on the screen, the view system 218 can easily become a "bottleneck" for display information and prevent rapid changes of the display by the application threads 202 and 216. A delay in the redrawing of the screen when views are moved or repositioned by the user often manifests itself by the appearance that the views and windows are being constructed in a piecemeal fashion which becomes annoying and detracts from the operation of the system.

Accordingly, it is an object of the present invention to provide a view system which can interface with application threads in such a manner that the screen display generated by each application thread can be quickly and effectively redrawn.

It is another object of the present invention to provide a view system which coordinates the display generation for all of the application threads in order to prevent the applications from interfering with each other or overwriting each other on the screen display.

It is yet another object of the present invention to provide a view system which can interact with the application threads by means of a simple command structure without the application threads being concerned with actual implementation details.

It is yet another object of the present invention to provide a view system which allows application developers who need detailed control over the screen display process to achieve this control by means of a full set of display control commands which are available, but need not be used by each application thread.

It is yet another object of the present invention to provide a view system which provides application developers with a powerful and flexible drawing environment which includes a virtual coordinate space, arbitrarily shaped views (and windows) and up to date drawing state information to facilite rapid, accurate drawing from multiple threads of execution.

It is yet another object of the present invention to provide a view system which provides application developers with an automatic system for keeping the display buffer up to date.

SUMMARY OF THE INVENTION

The foregoing problems are overcome and the foregoing objects are achieved in an illustrative embodiment of the invention in which an object-oriented viewing framework provides an extensible mechanism for grouping two or more windows and manipulating them as a group. The groups provide logical sets of windows for applying operations across address spaces to all the members of the group. The mechanism is implemented as a layer object which includes the linkages to the windows. Polymorphism and extensibility is also provided as part of the object-oriented architecture of the operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic block diagram of a prior art computer system showing the relationship of the application thread, the operating system, the screen buffer and, the display monitor.

FIG. 2 is a schematic block diagram of a modification of the prior art system shown in FIG. 1 which allows several application thread threads running simultaneously to generate display output in a single window.

FIG. 3 is a block schematic diagram of a computer system for example, a personal computer system on which the inventive object oriented viewing framework operates.

FIG. 4 is a schematic block diagram of a modified computer system showing the interaction between a plurality of application threads, the viewing framework, the window manager, and the screen buffer in order to display graphic information on the display monitor.

FIG. 5 is a block schematic diagram of the information paths which indicate the manner in which an application thread communicates with the inventive object oriented viewing framework and then directly to the screen buffer.

FIG. 6 is a schematic diagram indicating the typical appearance of a graphical user interface which is supported by a object-oriented viewing framework illustrating the components and parts of a window and the view hierarchy which is contained within.

FIGS. 7A and 7B illustrate the portions of the view hierarchy which must be redrawn when a view is resized.

FIGS. 8A and 8B is an illustrative flow chart of a method by which the object oriented viewing framework supports updating of dirty areas on the display by means of a background thread(s) in order to display information on the display screen.

FIG. 9 is an illustrative flow chart of a method used by the application thread to create a new view and install it in the view hierarchy.

FIG. 10 is an illustrative flow chart of a method used to support polymorphic initialization and finalization of a view framework object.

FIG. 11 is an illustrative flow chart of the method by which an application thread requests any state drawing information from the object oriented viewing framework.

FIG. 12 is a block schematic diagram of non rectilinear, disjoint views within the view hierarchy supported by the object-oriented viewing framework.

FIG. 13 is a block schematic diagram of the multiple coordinate spaces support by the object-oriented viewing framework.

FIG. 14 is a block schematic diagram of alignment of view objects based on their center of gravity specification by the object-oriented viewing framework.

FIG. 15 is an illustrative flow chart of the method by which a view is automatically, spatially laid-out by the object-oriented viewing framework.

FIG. 16 is a block schematic diagram of the visual effect "Magnifier View Effect" that applies a scaling transformation to the view below it in the view hierarchy as supported by the object-oriented viewing framework.

FIG. 17 is a block schematic diagram of the method used by the object-oriented viewing framework to enable grouping of multiple windows to be moved as a single layer.

FIG. 18 is an illustrative flow chart of the method by which an application thread makes use of a non multitasking aware object in a multitasking environment as provided by the object-oriented viewing framework

FIG. 19 is an illustrative flow chart of the method by which an application thread receives a positional event via the input system and the object-oriented viewing framework.

FIGS. 20A and 20B is an illustrative flow chart of the method by which an application thread receives changes in the object-oriented viewing framework in a single batch notification.

FIGS. 21A and 21B is a block schematic diagram of the method used by the object-oriented viewing framework to support read-only and read-write operations on the hierarchy and view objects.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

The invention is preferably practiced in the context of an operating system resident on a personal computer such as the IBM, PS/2, or Apple, Macintosh, computer. A representative hardware environment is depicted in FIG. 3, which illustrates a typical hardware configuration of a computer 300 in accordance with the subject invention. The computer 300 is controlled by a central processing unit 302 (which may be a conventional microprocessor) and a number of other units, all interconnected via a system bus 308, are provided to accomplish specific tasks. Although a particular computer may only have some of the units illustrated in FIG. 3, or may have additional components not shown, most computers will include at least the units shown.

Specifically, computer 300 shown in FIG. 3 includes a random access memory (RAM) 306 for temporary storage of information, a read only memory (ROM) 304 for permanent storage of the computer's configuration and basic operating commands and an input/output (I/O) adapter 310 for connecting peripheral devices such as a disk unit 313 and printer 314 to the bus 308, via cables 315 and 312, respectively. A user interface adapter 316 is also provided for connecting input devices, such as a keyboard 320, and other known interface devices including mice, speakers and microphones to the bus 308. Visual output is provided by a display adapter 318 which connects the bus 308 to a display device 322, such as a video monitor. The workstation has resident thereon and is controlled and coordinated by operating system software such as the Apple System/7, operating system.

In a preferred embodiment, the invention is implemented in the C++ programming language using object-oriented programming techniques. C++ is a compiled language, that is, programs are written in a human-readable script and this script is then provided to another program called a compiler which generates a machine-readable numeric code that can be loaded into, and directly executed by, a computer. As described below, the C++ language has certain characteristics which allow a software developer to easily use programs written by others while still providing a great deal of control over the reuse of programs to prevent their destruction or improper use. The C++ language is well-known and many articles and texts are available which describe the language in detail. In addition, C++ compilers are commercially available from several vendors including Borland International, Inc. and Microsoft Corporation. Accordingly, for reasons of clarity, the details of the C++ language and the operation of the C++ compiler will not be discussed further in detail herein.

As will be understood by those skilled in the art, Object-Oriented Programming (OOP) techniques involve the definition, creation, use and destruction of "objects". These objects are software entities comprising data elements and routines, or functions, which manipulate the data elements. The data and related functions are treated by the software as an entity and can be created, used and deleted as if they were a single item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.

Objects are defined by creating "classes" which are not objects themselves, but which act as templates that instruct the compiler how to construct the actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An objec