HK1117936A - System and method for providing a window management mode - Google Patents

Description

System and method for providing window management mode

Technical Field

Aspects of the present invention relate generally to managing user interface presentations in or by an operating system and, more particularly, to a method and system for applying operating modes to managing application window presentations in or by an operating system.

Background

As computers have grown in use in labor and personal life, the need for simpler computer use has also grown. Many operating systems today use window-based application configurations. The information is displayed on the display screen as several pages.

Thus, an application window is the core user interface facility of all Graphical User Interface (GUI) systems. While the appearance of application windows changes with the system, they have many common attributes, such as the ability to resize and reposition and the ability to exist between other applications associated with different applications. In general, multiple application windows may appear simultaneously on the screen, stacked upon one another, typically in the order in which the windows were last accessed by the user.

When multiple windows are open simultaneously, it is difficult to quickly locate, navigate, and switch to the desired window. For example, the desired window is partially or fully obscured by other open windows. And the required window may be minimized or hidden. These situations are often referred to as window management problems.

Window selection interfaces have been proposed to address this window management problem by minimizing the need to sort through the different open windows. The window management solution in Microsoft corporation's Windows XP brand operating system includes a taskbar and Alt-Tab combination keys, each of which shows a list of open Windows in a different view than the host window. In the taskbar, controls representing individual application windows are copied and rendered in a manner that avoids overlap, allowing selection of a particular application window in an indirect mechanism even if the window is currently occluded. The Alt-Tab combo key invokes a secondary UI facility, like a toolbar control, that shows a duplicate list of all open and available application windows from which the user may select. However, these interfaces do not allow the user to view the contents of the window without the window being selected.

Recently, apple computing incorporated introduced Expos in the MAC OS X brand operating system. Expos provides the user with the ability to display all open windows as thumbnails on the desktop. In operation, when the user presses the F9 key, Expos é tiles the entire open window. That is, Expos adjusts the window size to a size where all open windows can be displayed in a non-overlapping fashion. In another aspect, Expos provides the user to display and view all open windows in a non-overlapping manner in a particular application. Specifically, when the user presses the F10 key, Expos tiles all open windows of the current application in a non-overlapping fashion while graying out all open windows associated with other applications. This facilitates the positioning and selection of previously invisible application windows, but does not support user interaction with the application windows in this mode.

Although Expos allows the user to view open windows at the same time, multiple windows are tiled on the screen, which can still cause some confusion. In addition, Expos is a temporary state, where once the user selects one of the tiled windows, the user interface returns to the Z-order mode, with the selected window at the top of the Z-order.

In one implementation proposed for the MAC OS X brand operating system, the thumbnail control of the minimized application window is presented in the Dock control, and the active application itself is presented on the desktop on the space not occupied by the Dock control. To select another application to open, the user may select the thumbnail control of the application window in the Dock, and the system may open the application window on the Dock and minimize the previously opened application window to the Dock.

It would be beneficial to provide a window management solution that allows a user to provide all applications in a tiled type format and allows the user to switch windows in focus and out of focus while maintaining a tiled view of the non-focused application windows.

Disclosure of Invention

Accordingly, there is a need to provide a window management solution that provides a facility in which application windows are tiled and focus can be switched between tiled windows, allowing a user to quickly and easily switch application windows in and out of focus.

The present invention solves the window management problem by introducing a new mode of operation that can be invoked or removed by the user at any time. According to one aspect, the present invention provides a method in which all inactive application windows are scaled down and can be organized in a manner that sets them "next to the currently active application window. In one implementation, in response to a command to invoke the new window management mode, the active application window remains at or near full size and is placed in a central or "ideal" position relative to the inactive application windows.

Benefits that may be realized by such organization include providing users with tools to easily identify active and inactive application windows that are currently available for interaction. By keeping all inactive windows visible and available at any time, the user can easily identify and quickly activate the desired application window. Further, a user may work with multiple application windows without the application windows being overlapped or obscured by other application windows. Furthermore, user interaction with the active application window is not affected when the new window management mode is invoked. While shrinking in size, inactive application windows remain "alive" in the sense that they continue to update their content (i.e., refresh a web page or play video). The user may not interact with inactive application windows until they become active application windows.

Drawings

The foregoing summary of the invention, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings, which are included by way of example, and not by way of limitation with regard to the claimed invention.

FIG. 1A illustrates a schematic diagram of a general-purpose digital computing environment in which certain aspects of the present invention may be implemented;

FIGS. 1B through 1M illustrate a general computer environment supporting one or more aspects of the present invention;

FIG. 2 illustrates a display scenario representing multiple application windows presented in a Z-order configuration;

FIG. 3 illustrates a display scenario representing a plurality of application windows rendered in accordance with an aspect of the present invention;

FIG. 4 illustrates a display scenario representing a plurality of application windows rendered in accordance with another aspect of the present invention;

FIG. 5 illustrates a display scenario representing a plurality of application windows rendered in accordance with yet another aspect of the present invention;

FIG. 6 illustrates a display scenario representative of a plurality of application windows rendered in accordance with yet another aspect of the present invention;

fig. 7 and 8 provide a flow chart of an illustrative example of implementing the present invention.

Detailed Description

In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

FIG. 1A illustrates an example of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing system environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary computing system environment 100.

The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules are located in both local and remote computer storage media including memory storage devices.

With reference to FIG. 1A, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components of computer 110 may include, but are not limited to: a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to: random Access Memory (RAM), Read Only Memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory 130 includes storage media in the form of volatile and/or nonvolatile memory such as ROM 131 and RAM 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1A illustrates operating system 134, application programs 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1A illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to: magnetic cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.

The drives and their associated computer storage media discussed above and illustrated in FIG. 1A, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1A, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a digital camera 163, a keyboard 162, and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a pen, stylus and tablet, microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus 121, but may be connected by other interface and bus structures, such as a parallel port, game port or a Universal Serial Bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.

The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1A. The logical connections depicted in FIG. 1A include a Local Area Network (LAN)171 and a Wide Area Network (WAN)173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or any means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1A illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. The existence of any of various well-known protocols such as TCP/IP, ethernet, FTP, HTTP and the like is presumed, and the system can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Any of a variety of conventional web browsers can be used to display and manipulate data on web pages.

A programming interface (or simply, interface) may be viewed as any mechanism, process, or protocol for communicating one or more code segments with or accessing a function provided by one or more other code segments. Further, a programming interface may be viewed as one or more mechanisms, methods, function calls, modules, objects, etc. that enable a component of the system to be communicatively coupled to one or more mechanisms, methods, function calls, modules, etc. of other components. The term "segment of code" in the above sentence is intended to include one or more instructions or one or more lines of code, and includes, for example, code modules, objects, subroutines, functions, and so on, regardless of the terminology applied or whether the code segments are separately compiled, or whether the code segments are provided as source code, intermediate code, or object code, or whether they are located on the same or different machines or distributed across multiple machines, or whether the functionality represented by the segments of code are implemented entirely in software, entirely in hardware, or a combination of hardware and software.

Conceptually, a programming interface can be generally thought of as shown in FIG. 1B or FIG. 1C. FIG. 1B illustrates interface 1 as a conduit for first and second code segment communications. FIG. 1C illustrates an interface including interface objects I1 and I2 (which may or may not be part of the first and second code segments) that enable the first and second code segments of the system to communicate via medium M. In the view of FIG. 1C, the interface objects I1 and I2 can be considered as separate interfaces of the same system, or the objects I1 and I2 and the medium M can be considered to constitute the interface. Although fig. 1B and 1C show a bi-directional flow and interfaces on both sides of the flow, some implementations may have information flow in only one direction (or no information flow as described below) or interface objects on only one side. By way of example, and not limitation, terms such as Application Programming Interface (API), entry point, method, function, subroutine, remote procedure call, and Component Object Model (COM) interface are encompassed within the definition of programming interface.

Aspects of such a programming interface may include the method whereby the first code segment sends information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) to the second code segment; a method whereby the second code segment receives the information; as well as the structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, the underlying transmission medium itself (whether wired or wireless or a combination of both) is not critical to interface operation, so long as the information is transmitted in the manner defined by the interface. In some cases, information may not be transferred in a single or double direction in the conventional sense, as information transfer may be via another mechanism (e.g., information placed in buffers, files, etc. separate from information flow between code segments) or non-existent, as when one code segment simply accesses functionality performed by a second code segment. Any or all of these aspects may be important in a given situation, e.g., depending on whether the code segments described above are part of a system in a loosely coupled or tightly coupled configuration, so this list should be considered illustrative and non-limiting.

The concept of a programming interface is well known to those skilled in the art and will be apparent from the above detailed description of the invention. However, other ways of implementing a programming interface exist, and unless expressly excluded, these too are intended to be encompassed by the claims set forth in this specification. The other approaches described above are more sophisticated or complex than the simplified views of fig. 1B and 1C, but they still accomplish similar functions to achieve the same overall result. Some illustrative alternative implementations of a programming interface will now be described briefly.

A. Factorization of

A communication from one code segment to another may be accomplished indirectly by breaking the communication into multiple discrete communications. This is schematically illustrated in fig. 1D and 1E. As shown, some interfaces are described in terms of divisible sets of functionality. Thus, the interface functionality of FIGS. 1B and 1C may be factored to achieve the same result, just as one may mathematically provide 24 or 2 times 3 times 2. Thus, as shown in fig. 1D, the function provided by interface 1 can be subdivided into transforming the communication of that interface into multiple interfaces with the same result: interface 1A, interface 1B, interface 1C, etc. As shown in FIG. 1E, the functions provided by interface I1 may be subdivided into interfaces I1a, I1b, I1c, etc. with the same results achieved. Similarly, interface I2 of the second code segment that receives information from the first code segment may be factored into multiple interfaces I2a, I2b, I2c, etc. When factorized, the number of interfaces included in the first code segment need not match the number of interfaces included in the second code segment. In either case of FIGS. 1D and 1E, the functional spirit of interfaces 1 and I1 remains the same as in FIGS. 1B and 1C, respectively. The factoring of interfaces may also follow associative, commutative, and other mathematical properties, making the factoring difficult to identify. For example, the order of operations may not be important, and thus a function performed by an interface may have been performed by another piece of code or interface, or performed by another component of the system, before reaching the interface. Moreover, those skilled in the programming arts will appreciate that there are a variety of ways to make different function calls that achieve the same result.

B. Redefining

In some cases, it may be possible to ignore, add, or redefine certain aspects (e.g., parameters) of a programming interface while still achieving the desired results. This is shown in fig. 1F and 1G. For example, assume that interface 1 of FIG. 1B includes a function call Square (input, precision, output), i.e., includes three parameters input, precision, output and is a call issued from a first code segment to a second code segment. If the intermediate parameter precision is not involved in a given scenario as shown in FIG. 1F, it does not matter to ignore the parameter or even to replace it with a "meaningless" (in this case) parameter. An additional parameter may also be added that is not relevant. In either case, the squaring function can be implemented as long as the output is returned after the input is squared by the second code segment. precision is preferably a meaningful parameter for some downstream or other part of the computing system; however, once it is recognized that precision is not necessary for the limited purpose of calculating the square, precision may be replaced or ignored. For example, instead of transmitting a valid precision value, a meaningless value such as a birth date may be transmitted without negatively affecting the result. Similarly, as shown in FIG. 1G, interface I1 may be replaced by interface I1' redefined to ignore or add parameters to the interface. Interface I2 may similarly be redefined as interface I2', redefined to ignore unnecessary parameters or parameters processed elsewhere. The emphasis here is that in some cases, a programming interface may include aspects (such as parameters) that are not needed for some purpose, and thus may be ignored or redefined, or processed elsewhere for other purposes.

C. Embedded (INLINE) coding

It is also feasible to combine some or all of the functionality of two separate code modules such that the "interface" between them changes form. For example, the functions of FIGS. 1B and 1C may be transformed into the functions of FIGS. 1H and 1I, respectively. In FIG. 1H, the first and second code segments of FIG. 1B are merged into a module that contains both. In this case, the code segments may still communicate with each other, but the interface may be adapted to a form more suitable for a single module. Thus, for example, formal call and return statements may no longer be necessary, but similar processing or responses pursuant to interface 1 may still be in effect. Similarly, as shown in FIG. 1I, some (or all) of interface I2 from FIG. 1C may be written inline into interface I1 to form interface I1 ". As shown, interface I2 is split into I2a and I2b, and interface portion I2a has been encoded inline to form interface I1 "with interface I1. For a specific example, consider that interface I1 from FIG. 1C performs a function call square (input, output), which is received by interface I2, and after the value passed by input is processed (i.e., squared) by the second code segment, the squared value is returned by output. In this case, the processing performed by the second code segment (squaring input) can be done by the first code segment without calling the interface.

D. Separation of

A communication from one code segment to another may be accomplished indirectly by breaking the communication into multiple discrete communications. This is schematically illustrated in fig. 1J and 1K. As shown in fig. 1J, one or more pieces of middleware (split interfaces, as they split functions and/or interface functions from the original interface) are provided to transform communications on the first interface (interface 1) to adapt them to different interfaces, in this case interface 2A, interface 2B and interface 2C. This may be implemented, for example, in a situation where there is an installed base of applications designed to communicate with, for example, an operating system according to the interface 1 protocol, but the operating system is changed to use different interfaces (interface 2A, interface 2B and interface 2C in this case). The point is that the original interface used by the second code segment is changed to be no longer compatible with the interface used by the first code segment, so the old interface is made compatible with the new interface using the intermediary. Similarly, as shown in fig. 1K, a third code segment may be introduced, where communication from interface I1 is received over divorce interface DI1 and interface functionality is transmitted over divorce interface DI2 to interfaces I2a and I2b, for example, which are redesigned to work with DI2 but provide the same functional result. Similarly, DI1 and DI2 may work together to transition the functionality of interfaces I1 and I2 of FIG. 1C to a new operating system, while providing the same or similar functional results.

E. Rewriting and recording medium

Yet another possible variation is to dynamically rewrite the code to replace the interface functionality with something else that achieves the same overall result. For example, there are systems in which an intermediate language (e.g., Microsoft IL, Java, ByteCode, etc.) is provided to a just-in-time (JIT) compiler or interpreter in an execution environment (such as that provided by a Net framework, Java runtime environment, or other similar runtime environment). A JIT compiler can be written to facilitate dynamically transforming communications from a first code segment to a second code segment, i.e., to conform them to the different interfaces required by the second code segment (either an original or a different second code segment). This is shown in fig. 1L and 1M. As shown in fig. 1L, the method is similar to the separation case described above. This may be achieved, for example, in a situation where an installed base of applications is designed to communicate with the operating system according to the protocol of interface 1, but the operating system is subsequently changed to use a different interface. The JIT compiler can be used to conform communications during communications from an installed-base application to a new interface of the operating system. This method of dynamically rewriting the interface may be used to dynamically factor or modify the interface, as shown in FIG. 1M.

It is also noted that the above-described scenarios for achieving the same or similar result as an interface via alternative embodiments may be combined in different ways, in series and/or in parallel, or with other intervening code. Thus, the alternative embodiments shown above are not mutually exclusive and may be mixed, matched and combined with each other to produce the same or equivalent situation as the general situation shown in fig. 1B and 1C. It is also noted that, as with most programming constructs, there are other similar ways of implementing the same or similar functionality of an interface which may not be described herein, but which may be represented by the spirit and scope of the invention, i.e., it is noted that these are at least partially the functions illustrated by the interface and the beneficial results realized thereby which underlie the value of an interface.

Illustrative embodiments

FIG. 2 illustrates a display scenario 200 in which multiple open windows overlap one another. The various windows 202, 204, 206, 208, and 210 are shown in a Z-order (Z-order) orientation. Those skilled in the art will appreciate that the Z-order of window orientation is well known in the art. In FIG. 2, window 202 is higher in Z-order than windows 204, 206, 208, and 210. Window 204 is higher in Z-order than windows 206, 208, and 210. Window 206 is higher in Z-order than windows 208 and 210. Window 208 is higher in Z-order than window 210. The window 210 is at the bottom of the Z-order in this example. The term "orientation" as used herein is defined herein to include adjustments to the visual appearance of a window or group of windows, such as the size or shape of the window and a shared common boundary between or around at least two windows.

For purposes of the present invention, a "desktop space" is a display area on a display that allows a window corresponding to an application, i.e., an application window, to be displayed. Desktop space 201 in fig. 2 provides such an example. A taskbar 212 at the bottom of the display indicates the currently used window that is visible or minimized. A taskbar is a specific implementation of an on-screen remote control for listing and allowing window manipulations such as activation, movement, hiding, and minimization. It should be appreciated that the desktop space is separate from and does not overlap with controls on the display, such as a taskbar.

The window 202 may be represented by a taskbar button 214. Window 204 may be represented by taskbar button 216. Window 206 may be represented by taskbar button 218. The window 208 may be represented by a taskbar button 220. The window 210 may be represented by a taskbar button 222. Taskbar buttons 224, 226 and 228 represent application windows that have been hidden or minimized. When one or more application windows completely occlude an application window in the Z-order, the application window becomes hidden in the Z-order. Likewise, an application may automatically become hidden after a predetermined amount of inactivity. For example, if the user does not interact with the application window for thirty minutes, the application window is removed from the desktop space 201, but is still accessible through the toolbar button 214 corresponding to the application window. The application window may become minimized in response to a user command. As with the example shown in FIG. 2, five windows are shown open on the desktop space 201, while eight windows, including three hidden or minimized windows, are visually shown on the toolbar 212. The order of the toolbar buttons may represent an order in which the corresponding windows open sequentially from left to right (not shown).

The display scenario 200 in FIG. 2 illustrates a common problem with graphical user interface systems. In FIG. 2, at least the application windows 204, 206, 208, and 210 are partially obscured by one or more other application windows that are positioned above them in Z-order. Thus, the content and accessibility of the underlying application windows are difficult to discern.

According to aspects of the present invention, a new mode of operation for window management is introduced. In some aspects, the new mode may be invoked or removed by the user at any time. For example, a user may issue a command, such as a keyboard or mouse command, to invoke or activate the mode and similarly release the mode. In one aspect, the new window management mode of operation may be invoked from the display scenario 200. For the purposes of this description, the new mode of operation is described as if it were invoked from the display scenario 200 shown in FIG. 2. It should be understood that the mode may be invoked from many different display scenarios at any time. Alternatively, the new window management mode of operation may be configured as a default mode. Invocation of the window management mode does not affect the typical user interaction with the application window contents and controls (i.e., buttons and text regions). In at least some aspects, the user may perform all tasks in the new operating mode that she may perform through the application window in the display scenario 200.

According to certain aspects, this mode provides a method for managing the presentation of inactive windows, wherein inactive application windows are reduced in size and organized in a manner that "sets them aside" from the currently active window. For purposes of the present invention, the term "downsize" is defined to mean a reduction in size sufficient to distinguish inactive application windows from active application windows, e.g., inactive sizes may be reduced by 50% or more. The degree of scaling allows the outline delineating the inactive window to be clearly separated from the active window, but not to scale the application window to an unrecognizable excessive degree. The degree of reduction may be preset or may fall within a predetermined range depending on the number of inactive application windows, or may be some other function depending on the inactive application. In some aspects, it is preferable to make the zoom out to maintain the relative ratio to help the user identify the zoomed out application window.

Benefits that may be realized by such organization include providing a user with a facility to easily identify active and inactive application windows that are currently available for interaction. By keeping all inactive windows visible and available at any time, the user is able to easily identify and quickly activate the desired application window. Further, a user can view or otherwise use multiple application windows without any of the application windows being covered or obscured by other application windows.

According to some aspects, upon invocation of the operating mode, the active application window is rendered at or near full size and may be placed in a position on the desktop space relative to the inactive application windows. In some aspects, the location may be dynamically determined by the computer system based on the available desktop space, the size of the active application window, and the total number of windows. In this example, it may be considered that the system is determining an "ideal" location. Optionally, the location may also be pre-configured by the user. For purposes of the present invention, "full size" refers to the size of the application before invoking the mode, while "near full size" refers to at least 80% of full size and may be greater than full size.

In terms of operation, according to an aspect, invocation of the mode does not affect the underlying functionality of the application window. For example, user interaction with an active application window is not affected when the mode is invoked. While inactive application windows are scaled down in size, they remain "alive" and have their content continually updated (i.e., refreshing a web page or playing a video). However, in some aspects, user interaction with an inactive application window does not occur until the application window is made active.

Other aspects of the invention allow inactive application windows to become active by swapping positions with active application windows in response to a user selecting an inactive application window. In these aspects, when selected, the inactive application window is resized to or near full size and switches relative positions to the previously active application window that was reduced in size. This behavior is somewhat analogous to the known behavior of selecting an inactive application window that is below the active application in the Z-order such that the inactive application window becomes the topmost window in the Z-order and becomes active.

Fig. 3-6 provide display scenarios that may be used to illustrate some of the above aspects. Referring to FIG. 3, invoking the window management mode from the display scenario 200 of FIG. 2 results in a display scenario 300. Invocation of the window management mode may occur in response to a command such as a user selecting an input control representing a keyboard input (such as a Win-Tab keyboard), a voice command, or other type of user input. The application window may transition from the display scenario 200 to the display scenario 300 through animation.

In response to the mode call, all inactive application windows, whether displayed, hidden, or minimized, may be adjusted and positioned on the desktop space 201 such that all windows are visible and no application windows overlap. The active application window is rendered at or near full size and repositioned within the desktop space 201, for example to accommodate the display of the scaled down inactive application windows. Referring to FIG. 3, the active application window 202 is the same application window as that active in FIG. 2 and located at the top of the Z-order. Inactive application windows, presented in a scaled down form, include the various application windows, including applications 204, 206, 208, and 210, that are at least partially visible in the desktop space of fig. 2, as well as application windows 230, 232, and 234, which are hidden or minimized in fig. 2 and correspond to taskbar buttons 224, 226, and 228. In FIG. 3, the display scenario 300 shows inactive application windows rendered in the desktop space 201 in a row above the taskbar control 212, although this rendering style is merely illustrative.

In some aspects of the invention, upon invocation of the mode, the active application window may be repositioned to a predetermined position or its position determined based on current conditions. The current conditions may include, among other things, the number of inactive application windows, the degree to which the inactive application windows are reduced, the location on the desktop space at which the reduced windows are rendered in response to a command invoking the mode, the orientation of the screen (e.g., portrait), and the total area of the desktop space. In general, an algorithm can be used to consider one or more of the above conditions to determine the location of the active application window. In some aspects, the active application window may be centered in the available desktop space based on the boundaries of the desktop space and the location where the inactive application window is rendered. Fig. 3 shows the active application window 202 in such a central location. Alternatively, the location at which the active application window is presented may be pre-configured by the user or the user may select parameters that affect the location at which the active application window is positioned.

After invoking the new mode, the user may still continue to interact with the active application window in a conventional manner. In at least one aspect, no window or control interaction can be affected by the invocation of the new window management mode. Also in some aspects, window management mode may be closed using commands such as those similar to those described for invoking the mode. When the mode is switched off from the display scenario 300, then the display scenario may return to the display scenario 200. Alternatively, inactive application windows that were previously minimized or hidden may be rendered in Z-order on the desktop space 201. Of course, interacting with the application window in the new mode of operation may affect how and whether the application window is rendered in the desktop space 201 and where the application window is located in the Z-order when the mode is closed.

Selecting an inactive application window from a row of scaled-down inactive application windows or its corresponding taskbar button in FIG. 3 swaps the window into an active application window 202. Thus, a user issuing a command, such as through a pointing device, selecting a scaled-down inactive application window 206, or selecting a taskbar button 218 corresponding to the inactive application window 206 may cause the inactive application window 206 to swap relative positions in the desktop space 201 with the active application window 202, as shown in FIG. 4. In this case, the inactive application window 206 is made the active application window and rendered at or near full size in the same relative position that the previously active application window 202 occupied. Also, application 202 is made an inactive application window and rendered in a scaled down form in the inactive application window row in desktop space 201. The exchange of relative positions may be performed by the application window transitioning through animation from one position to another. For example, the inactive application window may grow (zoom in) to replace the active application window, while the active application window shrinks (zoom out) to replace the previously inactive application window. As alluded to in the description with reference to FIGS. 3 and 4, aspects of the present invention provide a separate facility for inactive application windows from the taskbar 212 through which a user may select an application for interaction.

It should be appreciated that the inactive application windows may be presented in different presentation styles, such as horizontally oriented in a row at the top of the desktop space 201, or vertically oriented in a column to one side of the desktop space as shown in FIG. 5, a combination of rows and columns, or any other orientation that allows a user to easily identify the active application window and each of the inactive application windows. According to one aspect, where a user has two display monitors, the active application window may be presented on one display screen while the inactive application may be scaled down and presented on a second display screen. To accommodate application windows of different sizes and orientations, the facility that manages the presentation of inactive application windows can collectively adjust all or individually repositioned windows to ensure that all windows remain in the desktop space 201. In situations where many inactive windows are included, it is appropriate to present the active application window at less than, but close to, the full size of the application window. It should be appreciated that a user may issue a command when to change a presentation style such as fig. 4 (e.g., horizontal orientation) to a presentation style such as fig. 5 (e.g., vertical orientation). Such changes between selectable presentation styles may occur through animation transitions. Also, the active application window 206 may change relative position as the presentation style becomes more centered relative to the desktop space 201, as shown between FIG. 4 and FIG. 5.

According to another aspect of the invention, additional application windows may be removed from the facility that manages the list of inactive application windows. In order to accommodate the use of users who are familiar with managing multiple open application windows or who desire to take advantage of multiple open application windows (i.e., drag or drop tasks), the new mode allows additional application windows to be included with the active application window. In this case, an inactive application window may be removed from the list of inactive application windows that are scaled down and instead rendered at or near full size with the active application window. While this aspect reintroduces the application window management problem, it is implemented on a user-controlled basis through a smaller, more manageable set of application windows.

An example of the present implementation will be described with reference to fig. 6. According to FIG. 6, a user may identify additional windows to be rendered at or near full size with the active application window by issuing a command, such as a right click or keyboard entry while hovering over an inactive application window. In the example of FIG. 6, when an application 234 is selected to be removed from the list of inactive application windows managed by the facility in response to a user command, the application window 232 is the active application window, after which the application 234 is rendered at or near full size and becomes the active application window that overlaps the previously active application window 232. The user may then perform operations involving both windows, such as drag and drop operations, on both application windows, both at or near full size. In this case, the user can interact with the application windows 232 and 234 in the same manner as the user interacts with the application windows in the desktop space 201 of FIG. 2. For example, selection of application 232 may move the window to the top of the Z-order to overlap application window 234. Other inactive application windows may also be added to the group by using a specific command. The specific command may be closed if each application window that is not in focus is presented in a scaled down form while other inactive application windows remain on the facility's list of inactive application windows.

If the user issues a conventional selection command selecting inactive application window 230 in FIG. 6, similar to that described with reference to FIG. 3, the selected inactive application window 206 will swap relative positions in desktop space 201 with application window 234, becoming the active application window and overlapping application window 232.

FIG. 7 provides a flowchart showing the steps involved in an illustrative implementation of the present invention. In step 701, the operating system receives a command to invoke a new window management mode. At step 703, the active application window is rendered at or near full size, and at 705, the inactive application windows are disposed alongside the active application window and rendered in a scaled down form, wherein no application windows overlap each other. In step 707, the operating system determines whether a command is received to select an inactive application window, either directly or via a toolbar button. If so, then at step 709, the operating system determines whether the selection command is a specific command requesting that the inactive application window be removed from the window management facility. If not, the mode operates by making the currently active application inactive and the selected inactive application window active at step 711. At step 713, the previously active application window and the selected application window exchange relative positions, and the previously active application window is rendered in a scaled down form while the selected application window is rendered at or near full size. Control then returns to step 707.

If no inactive application windows have been selected in step 707, then the operating system determines whether the window management mode has ended or is closed in step 715. If the mode has ended, then the application windows are rendered in the appropriate Z-order representation in step 717, where some of the windows may not be rendered in the Z-order and are hidden or minimized, as the case may be. Thereafter, the process ends.

If at step 709 a particular command has been selected requesting a multi-window operation, such as described with reference to FIG. 6, control moves to step 801 in FIG. 8. At step 801, the selected inactive application window is removed from the list of inactive application windows managed by the window management facility. At step 802, the currently active application window is made inactive and the selected application window is made active. At step 805, the selected application window is rendered at or near full size, overlapping the previously active application window. Control then returns to step 707 of fig. 7.

In another implementation of the invention, various aspects of the invention may be implemented through an Application Programming Interface (API). For example, a public API may interface with an operating system to allow the operating system to provide various features of the present invention. In one embodiment, a software architecture stored on one or more computer-readable media for processing data representing a Z-order of overlapping windows on a computer display includes at least one component configured for rendering an application window at the top of the Z-order at or near full size in a desktop space and rendering application windows below the top of the Z-order in a scaled down form in the desktop space, wherein no rendered application windows overlap one another; and at least one application program interface for accessing the component. The API may receive a request to manage application windows by rendering the active application window at or near full size and scaling down the inactive application windows, access the functions necessary to perform the operation, and then send the results back to the operating system. The operating system may use the data provided from the API to implement various features of the present invention.

In another implementation, a programming interface available to the operating system is capable of executing instructions including intercepting an instruction to the destination module to render an active application window at the top of the Z-order and an inactive application window below the active application window, and providing instructions to the destination module to render the active application window at or near full size in the desktop space and the inactive application window in a scaled down form in the desktop space such that no rendered application windows overlap one another.

While illustrative systems and methods as described herein embodying various aspects of the present invention are shown, it will be understood by those skilled in the art that the invention is not limited to these embodiments. Modifications may be made by those skilled in the art, particularly in light of the foregoing teachings. For example, each of the elements of the above-described embodiments may be implemented alone or in combination and subcombination with elements of the other embodiments. It will also be apparent and understood that modifications may be made without departing from the true spirit and scope of the invention. Accordingly, the description is to be regarded as illustrative instead of restrictive on the present invention.

Claims (20)

1. A method of simultaneously displaying a plurality of application windows on a display screen, the method comprising:

in response to the first command, each inactive application window is rendered in a scaled down form in a desktop space and the active application window is rendered at or near full size in the desktop space, wherein none of the rendered application windows overlap one another.

2. The method of claim 1, wherein the active application window overlaps at least one inactive application window in the desktop space immediately prior to responding to the first command.

3. The method of claim 1, wherein, subsequent to responding to the first command, in response to a second command that selects a first application window,

rendering the first application window at or near full size in the desktop space,

making the first application window active,

presenting a second application window in a scaled down form in the desktop space, the second application window being an active application window presented at or near full size in response to the first command, and

deactivating the second application window.

4. The method of claim 3, wherein the first application window and the second application window interchange relative positions in the desktop space in response to the second command.

5. The method of claim 4, wherein interchanging relative positions comprises the first application window transitioning from its relative position to the relative position of the second application window via animation and the second application window transitioning from its relative position to the relative position of the first application window via animation.

6. The method of claim 1, wherein the active application window is presented in a position in the desktop space based on at least one of a number of the inactive application windows, a degree of reduction of the inactive application windows, and a position in which the inactive application windows are presented in response to the first command.

7. The method of claim 1, wherein each inactive application window is disposed next to the active application window.

8. The method of claim 1, wherein in response to the first command, the active application is rendered at full size.

9. The method of claim 1, wherein an inactive application window is hidden or minimized immediately prior to responding to the first command.

10. The method of claim 1, wherein in response to the first command, each inactive application window that partially overlaps with other application windows transitions through animation to be disposed in the desktop space beside the active application window.

11. The method of claim 10, wherein in response to the first command, the active application window transitions through animation to a predetermined location in the desktop space.

12. The method of claim 1, wherein presenting an active application window comprises presenting the active application window on a first display screen, and presenting each inactive application window comprises presenting each inactive application window on a second display screen different from the first display screen.

13. The method of claim 1, further comprising presenting a taskbar control in a control area separate from the desktop space, the taskbar control comprising a first button control corresponding to the active application window and a second button control corresponding to an inactive application window.

14. The method of claim 13, wherein the active application window is a first application window and the inactive application window is a second application window, the method further comprising:

after responding to the first command, in response to user selection of the second button control, performing the steps of:

the first application window is inactivated and,

making the second application window active,

rendering the second application window at or near full size in the desktop space, an

Presenting the first application window in a scaled down form in the desktop space.

15. A method of simultaneously displaying a plurality of application windows on a display screen, the method comprising:

in response to a first command, rendering a plurality of application windows in a reduced form in a desktop space and rendering a first application window at or near full size in the desktop space, an

In response to a second command, a second application is rendered in the desktop space at or near full size, wherein none of the plurality of application windows overlap the first and second application windows.

16. The method of claim 15, wherein one of the first application window and the second application window is at the top of the Z-order and overlaps the other of the first application window and the second application window.

17. The method of claim 16, wherein in response to a user selection of one of the first and second application windows that is below the top of the Z-axis order, moving the other of the first and second application windows to the top of the Z-axis order.

18. The method of claim 16, wherein, subsequent to responding to the second command, in response to a third command to select a third application window,

rendering the third application window at or near full size in the desktop space,

presenting one of the first and second application windows at the top of the Z-axis order in a scaled-down form in the desktop space, wherein neither any one of the plurality of application windows nor the other of the first and second application windows overlaps the third application window and the one of the first and second application windows,

wherein the third application window is one of the plurality of application windows.

19. The method of claim 18, wherein in response to the third command, the third application window intersects the one of the first and second application windows in relative position in the desktop space.

20. A software architecture stored on one or more computer-readable media for processing data representing a Z-axis order of overlapping application windows on a computer display, comprising:

at least one component configured to present application windows at or near full size at the top of a Z-axis order in a desktop space and to present application windows at a reduced form at the top of the Z-axis order in the desktop space, wherein none of the presented applications overlap with each other; and

at least one application program interface of the component is accessed.