Abstract:
Systems and methods for returning windows to an original location are described. When springing already open windows to a new location on a display space, it is desired to return that window to its original location for certain situations. A list is provided when the springing operation is initialized which captures information used to return the sprung window. According to exemplary embodiments, the relocation of various windows is tracked to ensure that each window is returned to an original location.

Description:
Notice: More than one reissue application has been filed for the reissue of U.S. Pat. No.  6 , 072 , 488 . This application is a reissue of U.S. Pat. No.  6 , 072 , 488  and is also a continuation of application Ser. No.  10 / 165 , 040  filed Jun.  6 ,  2002 , which is a reissue of U.S. Pat. No.  6 , 072 , 488 .  
    
    
     BACKGROUND 
     The present invention relates generally to graphical user interfaces for computer systems. More particularly, the present invention relates to methods and systems for replacing open windows which have been sprung to a new display location as controlled by graphical user interfaces. 
     The evolution of the computer industry is arguably unparalleled in its rate of growth and complexity. Personal computers, for example, which began as little more than feeble calculators with limited memory, tape-driven input and monochrome displays are now able to tackle almost any data processing task. While this meteoric increase in power was almost sufficient to satisfy the demand of application programmers and end users alike, the corresponding increase in complexity created an ease-of-use problem which the industry was somewhat slower in solving. Thus, designers were faced with a new challenge: to harness this computing power in a form usable by even those with relatively little computer training to smooth the transition of other industries into a computer-based information paradigm. 
     As a result, in the early to mid-1980&#39;s many new I/O philosophies, such as “user friendly”, “WYSIWYG” and “menu driven” came to the forefront of the industry. These concepts are particularly applicable to microcomputers, also known as personal computers, which are intended to appeal to a broad audience of computer users, including those who previously feared and mistrusted computers. An important aspect of computers which employ those concepts was, and continues to be, the interface which allows the user to input commands and data and receive results, which is commonly referred to as a graphical user interface (GUI). 
     One type of GUI is based on a visual metaphor which uses a monitor screen as a work surface called a “desktop” where documents are presented in relocatable regions termed “windows”. The user interacts with the computer by, for example, moving objects on the desktop, choosing commands from menus, and manipulating window controls, such as check-boxes and scroll bars. An exemplary desktop screen is reproduced as FIG.  1 . 
     The success of this type of interface is evident from the number of companies which have emulated the desktop environment. Even successful concepts, however, must continually be improved in order to keep pace with the rapid growth in this industry. The advent of multimedia, especially CD-ROM devices, has provided vast quantities of secondary storage which have been used to provide video capabilities, e.g., live animation and video clips, as regular components of application displays. With these new resources at their disposal, application designers, and others, desire more and more control over the appearance of the display, including the desktop environment and, in particular, objects on the desktop. 
     Windows, filing cabinets, folders and documents are several examples of conventional desktop objects which extend the desktop visual metaphor. Folder windows can be configured to “spring” open when a user holds an item over a container item (e.g., a disk, folder, catalog, mailbox, viewer, server, or trash icon) which has one or more folders therein. Folder windows that are sprung open are temporarily centered under the cursor or as close to this centered position as possible while remaining on one monitor. 
     Occasionally, the folder windows which are sprung open by the user&#39;s actions relative to a container object are already open elsewhere on the desktop. Consider, for example, that a folder entitled “Five” is embedded in a hierarchical tree of folders such that folder “One” holds folder “Two” which holds folder “Three” which holds folder “Four” which holds folder “Five”. That is, to open folder “Five”, a user would open folders One, Two, Three, Four and Five in that order. This could result, for example, in the cascaded series of open folder windows shown in FIG.  2 . Note that these folder windows are numbered  1 ,  2 ,  3 ,  4  and  5 , respectively, for ease of reference in this text and that the folders and their respective folder windows will both be referred to using the same numbers. 
     Now suppose that a user springs open a container which happens to include folder  3  therein. As mentioned above, folder windows which are sprung open are drawn centered at the cursor location, if possible. Thus, folder window  3  will be closed at its location in the display space between the cascaded folder windows  2  and  4  and redrawn at a location centered on the cursor. This example is illustrated in FIG.  3 . Note that the folder windows  1 ,  2 ,  4 , and  5  are opened in a first portion  10  of the display space  12 , but folder window  3  has been sprung open at a second portion  14  of the display space  12  centered about a cursor (not shown). A gap is left between windows  2  and  4  in the position vacated by folder window  3 . 
     When the user releases the mouse button, or otherwise completes the drag, only the destination folder and folders that were open before the drag operation began remain open, e.g., folders  1 - 5  in this example. If folder  3  is not the destination folder, then this window would close at its displayed location in portion  14  of display space  23 . Conventionally, folder window  3  would then be redrawn on top of folder window  5  in portion  10  of the display space  12  as seen in FIG.  4 . However, this is considered to be undesirable since folder  3  now appears out of order with respect to folders  1 ,  2 ,  4  and  5  and blocks the view of the title bars of the other folder windows. 
     SUMMARY 
     These and other problems and drawbacks of conventional systems and methods for replacing windows in graphical user interfaces are overcome according to the present invention. According to exemplary embodiments, open windows which are sprung to a new location on the display space are returned to their original location when the springing operation is concluded. A list or other data structure is created when a springing operation is initiated that identifies open windows on the desktop, their relationship to other windows in their original positions, and an indicator that tracks the status of these windows as sprung or unsprung. When the springing operation is concluded, sprung windows can be returned to their original position using the information found in the list or data structure which was created when the springing operation commenced. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing, and other, objects, features and advantages of the present invention will be more readily understood by those skilled in the art upon reading the following detailed description in conjunction with the drawings in which: 
         FIG. 1  shows a conventional desktop screen; 
         FIG. 2  illustrates an exemplary set of cascaded open windows used to describe exemplary embodiments of the present invention; 
         FIG. 3  shows the cascaded open windows of  FIG. 2  lacking one of the windows which has been sprung open to a new location on the display space; 
         FIG. 4  depicts the result of a conventional technique for returning the sprung window of  FIG. 3 ; 
       FIG.  5 (a) is a block diagram of an exemplary computer system which can be used to implement the present invention; 
       FIG.  5 (b) is a block diagram illustrating various exemplary functional units of the computer system of FIG.  5 (a); 
         FIG. 6  illustrates an exemplary data structure used to capture open window information according to an exemplary embodiment of the present invention; 
         FIG. 7  is a flowchart describing a technique for returning the sprung window of  FIG. 3  back to its original position as seen in  FIG. 2  according to an exemplary embodiment of the present invention; and 
         FIG. 8  illustrates another case wherein two windows are sprung from their original positions. 
     
    
    
     DETAILED DESCRIPTION 
     Exemplary embodiments of the present invention will be described in terms of various visual aspects created or drawn in a display space controlled by a graphical user interface. Those skilled in the art will appreciate that such an interface can, for example, be used in conjunction with a computer such as that illustrated in FIG.  5 (a). Therein, a personal computer is illustrated as having a box  16  which contains, among other elements, circuit boards associated with the computer&#39;s functions, a keyboard  18 , a pointing device  20  and a monitor  22  having a display space  24 . The circuit boards included in box  16  can include boards which accommodate functional units such as those illustrated by the block diagram of FIG.  5 (b). Therein RAM  30 , ROM  32 , processor  34 , and I/O  36  are all interconnected via system bus  38 . 
     Of course the personal computer illustrated in FIGS.  5 (a) and  5 (b) is purely exemplary of one type of computer system in which graphical user interfaces according to the present invention may be implemented. For example, although the display space  24  of the system depicted in FIG.  5 (a) consists of that provided by monitor  22 , those skilled in the art will recognize that additional display devices could be arranged proximate monitor  22  to create a display space bridging several monitors. Moreover, although the present invention is described herein by way of exemplary, illustrative embodiments, some of which refer to graphical user interfaces implemented using the Macintosh® computer system as a reference for explaining the present invention, those those skilled in the art will readily appreciate that systems and methods according to the present invention can be applied to any type of display system having a user interface. Those wishing additional information with respect to the Macintosh® system are referred to Inside Macintosh, Vols. 1-6. 
     Returning now to the discussion of spring loaded folders, according to exemplary embodiments of the present invention windows which were open at the beginning of a springing operation be returned to their original location at the end of the operation. In terms of the foregoing example, window folder  3  will be returned to its original position relative to folders  1 ,  2 ,  4  and  5  (as shown in  FIG. 2 ) in the portion  10  of the display space  12  rather than returning to portion  10  of the display space  12  as the front window (as shown in FIG.  4 ). Exemplary techniques for accomplishing this result will now be described with respect to  FIGS. 6 and 7 . 
     When a drag is initialized, a data structure is created which stores certain information relating to windows which are open in the display space at that point in time. Although the following text refers to this data structure as a “list”, those skilled in the art will readily appreciate that any data structure capable of holding such information could be used for this purpose, e.g., a database, an array, etc. A list  60  used to capture information relating to the example provided in  FIGS. 2 and 3  is illustrated as FIG.  6 . Therein each of the folder windows  1 - 5  is identified in the list  60  using a “Window ID” field. Of course the actual numerical value of this field will vary depending upon the system implementation, but will suffice to identify the open window and its original location in display space  12 . The order of the open windows can be established in the list  60  by, for example, listing these windows in front-to-back order. A location indicator is also associated with each open window to keep track of its current status, i.e., sprung or unsprung. Since folder windows  1 - 5  are all unsprung at the time of drag initialization, each of these indicators is set to a Boolean value indicating that they are unsprung, depicted as an “N” in FIG.  6 . 
     When folder window  3  is sprung to the portion  14  of the display space illustrated in  FIG. 3 , the list  60  of  FIG. 6  changes to reflect the springing of folder window  3  by changing the location indicator value to the Boolean value associated with a sprung, rather than an original, position e.g., the letter “Y” for FIG.  6 . When the user ends the drag operation, and assuming that folder window  3  is to be closed in display space portion  14 , folder window  3  will be returned to its original position among the cascaded, open windows  1 ,  2 ,  4  and  5  using the information in the list  60  at that time. This operation can be performed as illustrated in the exemplary flowchart of FIG.  7 . 
     Initially, the process begins by examining the window furthest to the back as rendered on the display space, e.g., WindowID  1  of list  60 , at block  70 . The WindowID of this window is compared, at decision block  72 , with the WindowID of the window to be returned, in this case folder window  3 . Until a match is found (block  72 ) or the end of the list is reached (block  74 ), the process iterates through each WindowID on the list from back to front by incrementing a list pointer after each set of decisions (at block  76 ) and branching back to the top of the loop. If the end of the list is reached without a match (“Yes” at block  74 ), then the process ends and the window to be returned is not redrawn in this portion of the display space. This can occur, for example, when a window which was not open at the time that the springing operation began is processed according to the present invention. 
     For the purposes of this example, however, a match will occur on the third iteration when the current WindowID has been incremented to three. Then the flow proceeds to block  78  where the next WindowID in the list  60  is examined to determine, at block  80 , if folder window  4  has been sprung by checking the status of the location indicator field of list  60 . In this example, as seen in  FIG. 3 , folder window  4  has not been sprung so the flow proceeds to block  82  where folder window  3  is redrawn behind window folder  4 , i.e., such that the configuration seen in  FIG. 2  is restored. 
     Consider now the case seen in FIG.  8 . Therein, folder window  4  has also been sprung and is shown beneath the sprung version of folder window  3  in display space portion  14 . Revisiting decision block  80  of  FIG. 7 , for the case depicted in  FIG. 8 , the flow would proceed via the “Yes” path to decision block  84  since folder window  4  has been sprung and is not in its original position in display space portion  10  as would be indicated by an appropriate location identifier value for WindowID  4  in list  60 . If folder window  4  was at the end of the list  60 , i.e., the frontmost window in the list, then the flow would proceed to block  86  where folder window three would be drawn as the frontmost window. However, this example includes window  5  in list  60  so the flow instead loops back to block  78  where window  5  is now examined. Since window  5  has not been sprung, window  3  is placed behind window  5  such that the window order from front to back in display space portion  10  will now be  5 ,  3 ,  2  and  1 . Note that by determining whether a window has been sprung prior to returning another window, the situation is avoided where, for example, window folder  3  is redrawn behind folder window  4  in display space portion  14  rather than among the cascaded open windows in display space portion  10 . 
     The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. For example, the present invention is described herein by way of exemplary, illustrative embodiments, some of which refer to graphical user interfaces implemented using the Macintosh® computer system as a reference for explaining the present invention. However, those skilled in the art will readily appreciate that systems and methods according to the present invention can be applied to any type of display system having a user interface. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims.