 |
Description  |
|
|
BACKGROUND OF THE INVENTION
This invention relates generally to computer user interfaces and
specifically to a computer user interface that has a first area for
displaying windows in an overlapped arrangement and a second area for
displaying windows in a tiled arrangement.
A popular way to present information to users of today's computer systems
is via a graphical user interface (GUI). GUIs are usually part of the
environment provided by the operating system of a computer. However,
application programs can also create their own GUI by displaying objects
on the screen independently of utilities provided by the operating system.
A combination of these two approaches can also be used.
While GUIs may vary from operating system to operating system and from
application program to application program, there are basic components in
contemporary GUIs that find themselves in virtually all GUIs. Most popular
GUIs use a "mouse and windowing" environment where the user interacts with
the computer by using a pointer displayed on the screen and manipulated by
a hand held "mouse" input device. Information is displayed to the user
within windows that are rectangular areas on the screen containing text or
graphics related to the operation of an application program or an
operating system. Other characteristic features common in GUIs are icons,
menus, etc.
A "window" is the central way to provide information to, and receive
information from, a user. There are usually one or more active windows on
the display screen at any given time. Each window conveys information
about an application program or other process executing in the computer.
There may be multiple windows for a single application program or process
where each window is used to convey different types of information. There
can be multiple views of the same information such as two text windows
showing overlapping portions of the same document. Typically, the computer
system displays information within the window and accepts information from
the user, sometimes in the form of special windows called "dialog boxes".
The user often has some control over the existence, placement and size of
a window and sometimes can even control the amount and type of information
conveyed by the window. For a more detailed discussion of the use of
windows in typical computer systems, see, e.g., "Microsoft Windows Version
3.1 User's Guide, " by Microsoft, Inc
Windows are manipulated both by the computer and by the human user. Windows
can be opened and closed, causing them to appear or disappear,
respectively, on the display screen. Usually windows can be resized by the
user so that their height and width may be adjusted. The information
within the window can be scrolled if the window is able to show only a
portion of the total information. Windows can be moved around on the
screen so that they may be positioned virtually anywhere and they may be
overlapped by positioning a portion of one window over another. When
windows overlap the "top" window is the only window that is completely
visible since the bottom window is partially obscured by any window or
windows on top of it.
As application programs become larger and more complex, the likelihood of
windows overlapping on the display screen increases. Typically, an
application program has a single main, or "parent, " window Within the
parent window. multiple "child" windows are displayed. During the
execution of an application program the child windows are manipulated by
both the computer and user and inevitably overlap. The presence of
multiple overlapping child windows on a screen requires that that user
constantly shuffle through the windows in order to find the correct window
with the information that is of interest at the moment. This is similar to
a person rummaging around on a cluttered desk trying to find the proper
document. A similar problem exists with parent windows, themselves, in a
multitasking environment when more than one application program is
executing. In this case the computer may cause one application program's
parent window to obscure the child or parent windows of another
application program.
Current GUIs, such as WINDOWS by Microsoft, Inc., and the Macintosh
operating system by Apple Computer, Inc., are not sufficiently helpful in
managing multiple overlapping windows. In these operating systems there is
no guarantee that critical information about a window will always be
visible.
For example, the title name in the "title bar" of a window might be
obscured along with the contents of the window. The GUI provides commands
for arranging windows so that at least a small portion of each window is
visible. This allows the user to grab and move the window or to bring the
window to the top so it is completely visible. However, the small portion
of the window that is visible is often not enough to identify the window
so the user must "click" on each window in turn until finding the proper
window. This is cumbersome when there are many windows on the screen and
only tiny portions of several windows' corners are exposed.
Another problem arises in that the user often wishes to view the
information in a window continuously during the operation of a program.
However, the computer may decide that another window is important if it is
being updated, for example. The computer attempts to bring the updated
window to the front of a pile of overlapping windows. In traditional GUIs
the user can get around this problem by resizing and moving windows so
that there is enough room to place the window of interest off to the side
in an area where it won't be overlapped. However, this requires a lot of
manipulation by the user that must be repeated every time the user wants
to insure that a different window isn't obscured. Also, there is no
guarantee that the computer, under the direction of the operating system
or an application program, won't decide to overlay additional windows over
the user's window of interest. When multiple windows are being updated
quickly it often becomes impossible for the user to see all of the
information desired due to obscured windows.
The user may also designate a window to always be "on top" of other windows
to solve the problem of being able to continuously view a window of
interest. This has the drawback that an updated window containing
important information can be obscured by the window given "top" priority
by the user. Another drawback is that only one window can be guaranteed to
be on top at any one time.
Application programs and operating systems attempt to alleviate these
problems somewhat by using a fixed "status line" at the bottom of the
parent window. However, the status line is very restrictive in that only a
small amount of text can be displayed and the user has no control over the
type of information that is designated for the status line.
Early operating systems used "tiled" or "cascaded" window arrangements to
eliminate the problem of overlapping windows. When windows are arranged in
a tiled manner, each window is adjacent to other windows that may exist on
the screen. That is, the window borders abut much like tiles on a floor.
An example of an early operating system that used this approach is
Microsoft Windows Version 1.0 by Microsoft, Inc. However, the tiled
approach has generally been given up in favor of the overlapped window
arrangement because the tiled arrangement was too limited in the number of
windows that could be displayed and in the user's ability to resize and
reposition windows.
The cascaded arrangement overlaps the windows but insures that at least a
small portion of each window is available for manipulation. As mentioned
above, this is often not enough to allow the user to identify each window
or to perform all of the functions desired in a window of interest.
From the above discussion it is apparent that problems exist in traditional
GUIs when multiple windows are displayed in that a window of interest may
be obscured. This is especially true when the computer system continually
opens and displays new windows of various sizes and importance in
different positions on the display screen during the execution of an
application program.
SUMMARY OF THE INVENTION
The present invention solves the problem of window management by providing
two separate areas on the display screen. The first area is the
traditional overlapped window area where windows are handled as with
traditional GUIs. The second area is the "tiled" area where windows are
not allowed to overlap. The tiled area is an area where windows selected
by a human user or the computer are placed without the possibility of
their being overlapped or obscured. The invention provides an efficient
interface that intelligently manages the placement of windows in the tiled
area. The present invention also provides for resizing of both overlapped
and tiled areas by automatically resizing the windows in each area, as
needed.
The invention includes a method for displaying multiple windows during the
execution of an application program in a computer. The computer includes a
processor and a display for displaying windows and other information. When
the application program is executed windows are generated which are
displayed on the screen by the processor. The steps in the method include
allocating a first area of the display as the overlapping window area;
allocating a second area of display as the tiled window area; designating
each window as overlapped or tiled; displaying overlapped windows in the
overlapping window area such that two or more windows overlap; and
displaying tiled windows in the tiled window area such that the windows
are tiled.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of a computer system suitable for use with the
present invention;
FIG. 2 is an illustration of basic subsystems in the computer system of
FIG. 1;
FIG 3 shows a parent window of an application program;
FIG. 4 shows a second display screen of the application program;
FIG. 5 shows a second view of some of the windows in FIG. 4;
FIG. 6 shows an example of a parent window having three windows that
include a special control feature of the present invention;
FIG. 7 shows a parent window as it appears immediately after a tile button
is activated;
FIG. 8 shows a parent window divided into an overlapped area and a tiled
area containing an arrangement of child windows;
FIG. 9 shows a top level diagram illustrating some of the basic steps
involved in a window managing method of the present invention;
FIG. 10 shows a flowchart of a routine for placing a child window into a
tiled area;
FIG. 11 is a flowchart of a routine for expanding a child window in a tiled
area;
FIG. 12A is a first illustration of windows in a tiled area to show how a
child window is expanded;
FIG. 12B is a second illustration of windows in a tiled area to show how a
child window is expanded;
FIG. 12C is a third illustration of windows in a tiled area to show how a
child window is expanded;
FIGS. 13A to 13C illustrate resizing of windows in a tiled region when open
space is not available;
FIG. 14 shows a flowchart of a routine for shrinking a tiled area;
FIG. 15A is a first illustration of a boundary being moved to shrink a
tiled area;
FIG. 15B is a second illustration of a boundary being move to shrink a
tiled area;
FIG. 15C is a third illustration of a boundary being moved to shrink a
tiled area;
FIG. 16A is a first illustration of an area boundary being moved to enlarge
a tiled area; and
FIG. 16B is a second illustration of an area boundary being moved to
enlarge a tiled area.
DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 is an illustration of a computer system suitable for use with the
present invention. FIG. 1 depicts but one example of many possible
computer types or configurations capable of being used with the present
invention. FIG. 1 shows computer system 1 including display device 3,
display screen 5, cabinet 7, keyboard 9 and mouse 11. Mouse 11 and
keyboard 9 are "user input devices." Other examples of user input devices
are a touch screen, light pen, track ball, data glove, etc.
Mouse 11 may have one or more buttons such as buttons 13 shown in FIG. 1.
Cabinet 7 houses familiar computer components such as disk drives, a
processor, storage means, etc. As used in this specification "storage
means" includes any storage device used in connection with a computer
system such as disk drives, magnetic tape, solid state memory, bubble
memory, etc. Cabinet 7 may include additional hardware such as
input/output (I/O) interface cards for connecting computer system 1 to
external devices such as an optical character reader, external storage
devices, other computers or additional devices.
FIG. 2 is an illustration of basic subsystems in computer system 1 of FIG.
1. In FIG. 2, subsystems are represented by blocks such as central
processor 10, system memory 11, display adaptor 12, monitor 13, etc. The
subsystems are interconnected via a system bus 14. Additional subsystems
such as a printer, keyboard, fixed disk and others are shown. Peripherals
and input/output (I/O) devices can be connected to the computer system by,
for example serial port 15. For example, serial port 15 can be used to
connect the computer system to a modem or mouse input device. The
interconnection via system bus 14 allows central processor 10 to
communicate with each subsystem and to control the execution of
instructions from system memory 11 or fixed disk 16, and the exchange of
information between subsystems. Other arrangements of subsystems and
interconnections are possible.
The present invention provides an efficient way to manage windows where
multiple windows are used and displayed. This applies when the computer
system is executing instructions from an operating system or application
program. The invention is discussed below primarily where an application
program, rather than an operating system, executes and displays multiple
windows. However, it will be apparent that the window management system of
the present invention can be readily applied to operating system functions
where the operating system is controlling the display of multiple windows.
FIG. 3 shows parent window 100 as it would appear on display screen 5 of
the computer system 1 in FIG. 1. Parent window 100 shows parent window 102
generated in response to the execution of an application program called
"MAX+plus II," manufactured by Altera Corp. This application program is
typical of application programs that display multiple windows. Parent
window 102 includes two "child" windows 104 and 106.
In normal operation, an application program such as MAX+plus II displays a
single parent window on the screen such as parent window 102 and, during
the course of execution, displays multiple child windows such as 104 and
106 in an overlapped manner. In FIG. 3, child windows 104 and 106 are not
overlapped but are shown one above the other. This is an initial view that
can be set up by the MAX+plus II software or at the user's discretion. In
the simple situation where only two windows of limited size are on the
screen there is sufficient space so that they may both be viewed easily in
their entirety. However, the MAX+plus II program is a large and complex
program for doing computer aided design (CAD) of electronic circuits.
During the course of executing MAX+plus II the computer system displays
many new windows that, of necessity, overlap each other.
FIG. 4 shows a second display screen of the MAX+plus II program. In FIG. 4
display screen 110 is now shown with five child windows 112, 114, 106, 118
and 116. Child window 106 of FIG. 4 is the same child window as child
window 106 of FIG. 3. Note that child window 104 of FIG. 3 has been
"iconized" that is it is displayed as an icon in FIG. 4
In FIG. 4, four of the five child windows are obscured child windows such
as 112, 114 and 116 need to be large and rectangular in order to
effectively display the detailed circuit diagrams and/or text information
within these windows. A child window such as child window 106 is a
scrolling status window where lines of text are displayed during the
course of application program execution in order to give warning messages
and status updates on the performance of a task In this case., the task is
the compilation of a circuit design description in order to determine
errors, optimize the circuit, etc.
A status window such as child window 106 has a preferred size of a long
width as compared to a relatively short height This is because the status
window displays messages that are typically one line per message This is a
convenient way for the user to view status messages since each line
corresponds to a different message and, once a message has been read by
the user, it is usually no longer of importance For this reason, the
status window only needs to display a few most recent messages The status
window has additional controls in the form of buttons such as buttons 120,
122 and 124 Note that in FIG. 4, the status window is largely obscured by
windows that have been overlaid, or overlapped, on top of it. The
overlapping of windows onto the status window renders the status window
almost useless Not only is most of the text information obscured, but
button 124 is mostly hidden from view so that, although the button is
still accessible by the small right-most portion, the identification of
the button as providing "Help on Message" has been lost In fact, the only
windows that are sufficiently visible to convey useful information are
child window 118 and, perhaps, child window 116 Note also that some of the
icons toward the bottom of the screen at 130 are obscured. In particular,
the right-most icons have lost their visual cues since the graphics
intended to convey what the icons represent are mostly hidden.
FIG. 5 shows a second view of some of the windows of FIG. 4 in parent
window 140. FIG. 5 shows child windows 116, 114, 106 and 112 in a
so-called "tiled" arrangement. In FIG. 5, each child window's border
touches the adjacent child window's border. Although the tiled arrangement
of FIG. 5 provides a solution to the problem of overlapping windows
obscuring desired information, this is not a desirable solution.
One problem with the tiled arrangement of FIG. 5 is that circuit schematic
windows 116 and 114 are not large enough to be useful. Another problem is
that status window 106 does not have the proper dimensions as before. Note
that the last two lines of status window 106 can no longer fit on a single
line and so must be put on two lines. Also, while status window 106 is too
small in the horizontal direction, it is now too large in the vertical
direction. There is extra space at 142 that is not being used in status
window 106.
The tiled arrangement of FIG. 5 is further restrictive in that no
additional windows may be displayed without drastically reducing the size
of the existing windows. Also, some windows, such as window 112, may only
be marginally useful and would be better left with less space allocation
on parent window 140.
FIG. 6 shows an example of a parent window, parent window 160, having three
windows that include a special control feature of the present invention.
In FIG. 6, each child window is equipped with a tile button such as tile
button 160 for window 106. In a preferred embodiment, the default display
is the overlapped display of the prior art as shown in FIG. 6. However, by
activating the tile button for a child window, the parent window is
divided into separate areas having different properties for displaying
windows.
FIG. 6 shows parent window 160 prior to any of the tile buttons of the
child windows being activated. Prior to activating a tile button, the
entire area in parent window 102 is used as an overlapping window area.
FIG. 7 shows parent window 160 of FIG. 6 as it appears immediately after
tile button 160 in status window 106 of FIG. 6 is activated. In FIG. 7,
display screen 170 is now separated into two areas. These areas are an
overlapped window area 172 and a tiled area 174. A horizontal boundary 176
is used to separate the two areas which each run the width of the
application window. Since no tiled area existed before the activation of
tile button 160, an initial tiled area is created with a height that is
the same height as child window 106. If one of the other windows 116 or
112 had, instead, been selected for placement in the tiled area by using
buttons 172 or 174, respectively, an attempt would be made to create a
tiled area at the bottom of the screen that was as high as the selected
window. In a preferred embodiment, the tiled area is allowed to
automatically grow to one half of the height of the parent window but can
be manually extended past this initial limit. Details on how the window
management system of the present invention handles the allocation of area
and window sizes are discussed below.
FIG. 8 shows parent window 180 where the parent window of the MAX+plus II
application program is divided into overlapped area 182 and tiled area 184
and the tiled area 184 contains a more complex arrangement of child
windows. The double-headed arrows in FIG. 8 show the directions that child
window borders may be dragged in order to change the sizes of the child
window and adjacent child windows. In addition, area boundary 186 may also
be moved in a vertical direction as shown by the double-headed arrow. The
way that the present invention provides for shrinking and enlarging
windows and overlapped and tiled areas will next be discussed in
connection with flowcharts that illustrate methods of the present
invention.
FIG. 9 shows top level diagram 200 that illustrates some of the basic steps
involved in a window managing method of the present invention. Prior to
executing step 202, it is assumed that an application program has been
selected for execution by either a user or the operating system. At step
202 space is allocated to the application program's parent window. This
step is usually performed by the operating system.
At step 204 minimum, maximum and natural sizes are assigned to each child
window that could appear during the execution of the application program.
This can be predetermined within the application program itself as defined
by the human programmer of the application program, or can be assigned by
the operating system as the child windows are opened. In the latter
method, the operating system assigns default values to most windows.
Another possibility is that the operating system would make an educated
guess as to the minimum, maximum and natural sizes for the window based on
the type of window and the information it displays, e.g., text, graphics,
etc.
Each window has a minimum, maximum and natural size for each of the
window's two dimensions, height (vertical dimension) and width (horizontal
dimension). The minimum dimensions determine the smallest size for the
dimension that the window can have and still be functional or be useful to
the user. The minimum size for a window can be chosen according to the
smallest size that permits the window to accommodate the minimum number of
control buttons and still remain functional. Or the minimum size can be
limited because of the type of information that the window displays, e.g.,
graphics, so that the window will not shrink beyond being able to display
recognizable data to the user.
The maximum dimensions, likewise, determine the maximum dimensions allowed
for the height and width of each window. The maximum dimensions are limits
on the growth of a window because making a window larger than the maximum
size in a certain dimension would not gain anything. For example, a window
that only displays text lines of up to 40 characters in width would have a
maximum width that would be just large enough to accommodate the 40
characters of text. Widening the window beyond this would just be a waste
of space within the window.
The natural dimensions for a window are the preferred sizes for the
window's height and width. The natural dimensions are between the maximum
and minimum sizes and are the preferred dimensions for the window. The
natural dimensions also determine the preferred aspect ratio as the ratio
of width to height. The preferred embodiment always attempts to display a
window in the preferred aspect ratio or as close to it as possible.
Returning to FIG. 9, at step 206, the application program is executed. The
execution of the application program invokes one or more of steps 208-216
for displaying a new child window 208, moving a child window between
overlapped and tiled areas 210, resizing tiled and overlapped areas 212,
repositioning/resizing a child window within the same area 214, and
closing an existing window 216. In general, the steps shown in top level
diagram 200 may be executed at different times and performed by different
processes within the computer system. These steps can be performed by the
operating system, the application program or a combination of both.
Further, steps may be repeated, especially steps 208-216 which are
repeated many times during the execution of an application program.
In the discussion below, certain steps critical to the present invention,
such as moving a child window from the overlapped area to the tiled area,
enlarging a child window within the tiled area and changing the size of
the tiled area, are discussed in detail.
Moving a Child Window from the Overlapped Area to the Tiled Area
A user may move a child window from the overlapped area to the tiled area
in three different ways. A first way iS for the user to "click and drag" a
window from the overlapped area to the tiled area and then "drop" the
window in an open space in the tiled area. This assumes that a tiled area
exists and that there is a space, or slot, in the tiled area for the
window to fit. A second way is for the user to click on the tile button
within the window to be moved as discussed above in FIG. 6 where tile
button 160 is shown within status window 106. A third way is for the user
to access a menu from the main menu bar of the parent window, such as main
menu bar 101 shown in FIG. 3.
In a preferred embodiment, the menu selection for placing a child window
into the tiled area is a "Penalize" command. Once a window is selected,
the selected window is placed into the tiled area (whimsically referred to
as the "Hog Pen") by choosing the "Penalize" command from the menu. The
product incorporating these features is anticipated to be "MAX+plus II
Version 5.2" by Altera, Corp.
Next, the flowchart of FIG. 10 will be discussed to illustrate basic steps
in a method of the present invention. In general, the flowcharts in this
specification illustrate one or more software routines executing in a
computer system such as computer system 1 of FIG. 1. The routines may be
implemented by any means known in the art. For example, any number of
computer programming languages, such as "C", Pascal, FORTRAN, assembly
language, etc., may be used. Further, various programming approaches such
as procedural, object-oriented or artificial intelligence techniques may
be employed.
The steps of the flowcharts may be implemented by one or more software
routines, processes, subroutines, modules, etc. It will be apparent that
each flowchart is illustrative of merely the broad logical flow of the
method of the present invention and that steps may be added to, or taken
away from, the flowcharts without departing from the scope of the
invention. Further, the order of execution of steps in the flowcharts may
change according to different implementations such as interrupt-driven,
polled, etc., event handling. A multiprocessing or multitasking
environment could allow steps to be executed concurrently. For ease of
discussion the implementation of each flowchart is referred to as if the
flowchart were implemented in a single "routine".
FIG. 10 shows flowchart 220 that describes a routine for placing a child
window into a tiled area. Steps 222-256 of flowchart 220 are performed by
the computer system. Routine 220 can be invoked when the user has
indicated that a window is to be moved to the tiled area by one of the
ways described above. Routine 220, or another routine similar to it, can
also be invoked when the application program or operating system needs to
place a window into the tiled area automatically.
Routine 220 is entered at step 222 after a child window has been selected
to be moved. The selected child window is referred to as the "selected
window." The coordinates, and thus the dimensions, for the parent window
and any existing overlapped or tiled areas are known as defined at step
202 in FIG. 9. It is assumed that minimum, maximum and natural sizes in
horizontal and vertical directions for the child window to be moved have
been defined as at step 204 of FIG. 9.
At step 224, a test is made as to whether a tiled area exists. If not,
execution proceeds to step 226 where the routine attempts to allocate a
tiled area that is at least as high as the selected window. At step 230, a
check is made as to whether the overlapped area, that is, the area inside
the parent window that is not within the tiled area, is not too small.
Note that in this discussion the overlapped area and the parent window are
initially the same area. That is, before a tiled area has been created the
overlapped area is the entirety of the parent window's interior.
In initially creating a tiled area, the overlapped area is considered "too
small" if the child window selected for placement in the tiled area has a
minimum vertical dimension that is greater than half of the vertical
dimension of the parent window. An attempt is made to make the tiled area
large enough to accommodate the child window's natural vertical dimension.
However, if the natural vertical dimension of the tiled window requires a
tiled area that is larger than one-half of the height of the parent window
then a smaller vertical dimension for the selected child window, up to the
selected child window's minimum dimension, is used, instead. Note that the
limitation of one-half of the parent window's height is arbitrary. This
size is chosen in the preferred embodiment since it provides a minimum
size for the overlapped area that is equal to the maximum size for the
tiled area, namely, one-half of the parent window. This limitation only
applies to the automatic creation and sizing of the tiled area. The
limitation can be overridden when the user manually adjusts the size of
the tiled or overlapped areas as described below. Other initial
limitations for the tiled area's vertical size may be used.
If, instead, at step 230 the overlapped area is determined to be too small,
step 236 is executed where the tiled area is made half as large as the
parent window. Note that the parent window itself may be resized by the
user. The parent may be resized regardless of minimum, maximum and natural
sizes for its child windows since the child window views are "clipped," in
accordance with methods well known in the art, when the child window views
can no longer fit within the parent window. At step 242, a check is made
as to whether the selected window can fit within the tiled area when the
tiled area is smaller than the height of the selected window. Such a fit
is possible by shrinking the selected window, up to its minimum vertical
dimension, as required. If the selected window can be made to fit inside
the tiled area by shrinking it (but not below its minimum height) step 246
is then executed to place the selected window to the right inside the
tiled area as before. Step 255 is executed to save the selected window's
previous coordinates in the overlapped area for later restoration. The
routine then exits at step 256.
If, at step 242, the selected window cannot be shrunk to fit in the
allocated tiled area because the minimum height of the selected window is
too large, execution proceeds to 254 where the user is informed that the
selected window cannot be fitted into a tiled area.
Returning to step 224, if a tiled area already exists when routine 220 is
entered, then the routine attempts to fit the selected window into the
existing tiled area.
At step 228, a check is made as to whether there are any existing spaces or
slots within the tiled area that are large enough to contain the selected
window. Regardless of the selected window's current size, the natural size
of the selected window are the dimensions used in attempting to make a
fit. If both the horizontal and vertical natural dimensions of the
selected window will fit into a slot in the tiled area, then step 248 is
executed. If a slot is larger than the selected window's natural size in
both dimensions then the window is placed into the slot in the lower left
corner of the slot with the window in its natural size. At step 248, if
multiple possible slots are available, then the lowermost, rightmost slot
is used. At step 252, the last position of the selected window in the
overlapped area, along with the selected window's size in the overlapped
area, is stored. This allows the selected window to be repositioned in the
overlapped area at a later time at the same place and in the same size as
it existed previously. The routine is exited at step 256.
Alternatively, if the check at step 228 determines that no slots exist in
the tiled area that can contain the selected window in at least the
selected window's natural size, execution proceeds to step 234. At step
234 a check is made as to whether there are any slots that have one
dimension greater than or equal to the selected window's corresponding
natural dimension and the other dimension greater than or equal to the
corresponding minimum dimension for the selected window. If so, step 232
determines whether there are multiple such windows and, if so, prioritizes
the slots so that the relative proportions of length to width based on the
natural dimensions for the window are maintained as closely as possible.
In other words, if the selected window has natural dimensions such that its
width is substantially greater than its height (i.e., a "landscape" aspect
ratio), then slots that can accommodate the window that while maintaining
the relative ratio of width to height will be chosen first. On the other
hand, if the window is one with an aspect where the height is
substantially greater than the width (i.e., a "portrait" type window) then
slots that maintain the greater height-to-width ratio will be chosen over
others, accordingly. At step 248, if there are multiple slots of high
priority, the largest of the multiple possible slots is chosen. If there
are multiple slots of the same largest size then the lowermost and
rightmost slot of the "largest size" slots is used. At step 252, as
before, the coordinates of the selected window in the overlapped area are
saved so that the selected window can be returned to the overlapped area
in its similar form if required by the user or the computer system.
If, at step 234, no slots were found with sufficient dimensions, step 240
is executed to check whether there are any slots that have both dimensions
greater than or equal to the corresponding minimum dimensions for the
selected window. If so, step 232 again tries to keep proportions for the
selected window roughly the same as for the selected window's natural
dimensions. That is, if the selected window is naturally a landscape,
slots will be chosen so that the width will be greater than the height.
Similarly, if the selected window is naturally a portrait type, slots will
be chosen so that the height is greater than the width when the window is
displayed in the slot. Steps 248, 252 and 256 are next executed as before.
If, at step 240, there are no slots that have dimensions greater than or
equal to both minimum dimensions for the selected window, step 250 is
executed to check whether the tiled area is at its maximum size. In the
preferred embodiment, the tiled area will only be allowed to grow to
one-half the height of the parent window as discussed above. However, the
user may manually extend the tiled area beyond this limitation as
described below.
If the tiled area is not yet at its maximum size, an attempt is made to
"grow" the tiled area to make it larger so that a selected window could be
made to fit into a larger slot in the larger tiled area. Step 244
accomplishes this by incrementally extending or enlarging the tiled area
upward. The details of extending the tiled area are discussed below.
Execution then returns to step 228 where, as before, a check is again made
for any slots that will fit the selected window according to the selected
window's natural sizes. If, at step 250, the tiled area cannot be "grown"
anymore, execution proceeds to step 254 where the user is informed that
the selected window cannot be made to fit into the tiled area. Where the
user has selected a window to move to the tiled area by using the menu
command from the main menu bar or the tile button within the selected
window, a message in the form of a dialogue box can alert the user that
the window cannot be moved to the tiled area.
Other means for alerting the user could be employed such as a warning beep.
Where the user has selected a window to move to the tiled area by clicking
and dragging the window, the preferred embodiment turns the pointer into a
"no entry" symbol when the user is in an area where the selected window
cannot be "dropped" to fit into a slot in the tiled area.
Thus, the discussion above in connection with routine 220 of FIG. 10
illustrates how a method for placing a child window in the tiled area is
implemented in a preferred embodiment of the present invention.
Expanding Windows in the Tiled Area
FIG. 11 is a flowchart of a routine 300 for implementing a method to expand
a child window in the tiled area. As described above in connection with
FIG. 8, windows in the tiled area may be expanded or shrunk by the user or
by the computer system executing an application program or operating
system. The user is able to expand and shrink windows in the tiled area by
clicking on the window borders and simply dragging the border into or away
from the window whose size the user wants to change. The problem with this
is that the dragging of the border might bring the border into contact
with a border of another window in the tiled area or with a boundary of
the tiled area when the window is being enlarged.
The example below describes expanding a window in the horizontal dimension
to the right. It will be apparent that the expansion could be to the left
by analogous steps or, likewise, upward or downward in the vertical
dimension.
Routine 300 is entered at step 302 where it is assumed that the user has
clicked on and is attempting to enlarge a selected window by moving the
border in the horizontal or vertical direction away from the selected
window. Where the computer system is automatically trying to enlarge a
window in the tiled area, the method for allowing the enlargement is
analogous to that described here for user expansion of a window in the
tiled area. At step 304 a check is made as to whether there is any open
space for the border to move in the desired direction.
Referring to FIG. 12A, parent window 320 is shown having overlapped area
322 and tiled area 324. Tiled area 324 includes child windows A, B and C.
Window A is a selected window and is to be expanded to the right as shown
by the arrow attached to it. In this case, there is open space to the
right of window A so the right-most border may be freely moved to the
right thus expanding window A.
Referring to FIG. 11, step 306 is next executed to allow the window to
expand to the right. It will be apparent that expansion in the vertical
direction follows a similar procedure. By "train" it is meant that when
there are contiguous windows adjacent to the moving border of the window
being expanded, the group of contiguous windows, other than the selected
window being expanded, is referred to as a "train". For example, in FIG.
12B in which only the tiled area 324 is shown, window A has been expanded
so that its border now contacts the left border of window B. Window B's
right border contacts the left bo | | |
