Custom tab ordering and replacementBackground
A multi-document application is an application in which multiple documents may be opened simultaneously and one of the documents is active and the other document is inactive. When a document is active, the document may be viewed in a main viewing area of the application. If the application allows editing of the document, the active document may also be edited. On the other hand, when a document is inactive, the document is not viewed in the main viewing area of the application. Instead, inactive documents are represented by tabs. To deactivate the current document and activate another document, a tab corresponding to the particular document is selected. When a document is opened, a new tab is created. Typically, the tabs are presented in a particular order.
As an example, a web browser may have multiple documents open in the form of web pages. Each web page has a respective tab along an upper portion of the web browser interface. To switch from one open web page to another, the user selects the tab associated with the web page that the user wants to see. The web browser responds to the selection by displaying the selected web page in a main viewing area of the web browser. As another example, some document editing programs, such as Visual Studio, use tabs that may be selected to control which document may be seen and edited in a main viewing area of the document editing program.
SUMMARY
At least one embodiment described herein relates to a multi-document application that includes a multi-document interface. The multi-document interface includes a viewing area configured to display one document at a time, even if multiple documents are open in the multi-document application. The multi-document interface also includes a tab group element that displays tabs, each tab having a control that permits visualization of a respective document in the viewing area.
For at least some documents opened by the multi-document interface, when a new document is opened in the multi-document application, the multi-document interface adds a new tab to the tab group element to represent the newly opened document. In one or more embodiments, when there is no space in the tab group element for a new tab to view, the multi-document interface hides at least one of the other tabs to make room for the new tab in the tab group element. When adapted to hide tabs, the multi-document interface uses the hiding criteria to decide which tab to hide. However, the criteria for deciding which tab to hide is configured by the user of the multi-document element, rather than being predetermined.
In one of many embodiments, the tab set includes a navigation control that allows a user to navigate the tabs in a manner that changes which of the tabs in the tab set element is visible. The type of navigation control may be configured by a user of the multi-document application, rather than predetermined.
In one of many embodiments, the ranking criteria of the ranking tab may also be configured by a user of the multi-document application.
This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Brief Description of Drawings
In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of various embodiments will be rendered by reference to the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting of its scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
FIG. 1 illustrates an example computing system that may be used to implement embodiments described herein;
FIG. 2 abstractly illustrates a multi-document application having a multi-document interface;
FIG. 3 abstractly illustrates a multi-document interface having a viewing area and a tab group element;
FIG. 4 illustrates an example multi-document interface in which there is a viewing area and a plurality of tabs, each tab corresponding to a document that may be viewed in the viewing area upon selection of the tab;
FIG. 5 illustrates an example configuration interface through which a user may configure a multi-document interface;
FIG. 6 illustrates a flow chart of a method for pinning tabs in a multi-document interface;
FIG. 7 illustrates a first example of a pinned tab, where the pinned tab is in the same row as the unstripped tab;
FIG. 8 illustrates a second example of a pinned tab, where the pinned tab is in a separate row from the unpinned tab;
FIG. 9 illustrates a coloring configuration interface that may be used to color tabs in a custom manner;
FIG. 10 illustrates a user interface in which colors available to correspond to items may be customized by a user, or at least displayed to a user;
FIG. 11 illustrates a user interface in which a user may set an expression that is evaluated to color a tab; and
FIG. 12 illustrates a multi-document interface in which tabs have been colored according to the expression of FIG. 11.
Detailed Description
According to embodiments described herein, a multi-document application is described that includes a multi-document interface that includes a viewing area that displays one document at a time and includes a tab group element that displays tabs, each tab having a control that permits visualization of the respective document in the viewing area. When a new document is opened in the multi-document application, the multi-document interface adds a new tab to the tab group element to represent the newly opened document. The user may configure hiding criteria used to determine which tabs to hide when there are too many tabs to visualize in a tab group element, ordering criteria for ordering tabs, and/or the type of navigation control that may be used to change the subset of tabs in the tab group element that are visualized. First, some introductory discussion regarding computing systems will be described with respect to FIG. 1. Then, embodiments of the multi-document application will be described with respect to fig. 2 through 12.
First, an introductory discussion regarding computing systems is described with respect to FIG. 1. Computing systems are now increasingly taking a wide variety of forms. For example, the computing system may be a handheld device, a household appliance, a laptop computer, a desktop computer, a mainframe computer, a distributed computing system, or even a device that is not traditionally considered a computing system. In this description and in the claims, the term "computing system" is defined broadly to include any device or system (or combination thereof) that includes at least one processor and memory having computer-executable instructions thereon that are executable by the processor. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed over a network environment and may include multiple computing systems that make up the same.
As illustrated in FIG. 1, in its most basic configuration, computing system 100 typically includes at least one processing unit 102 and memory 104. The memory 104 may be physical system memory, which may be volatile memory, non-volatile memory, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processor, memory, and/or storage capability may also be distributed. The term "module" or "component" as used herein may refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).
In the following description, embodiments are described with reference to acts that are performed by one or more computing systems. If such actions are implemented in software, the one or more processors of the associated computing system that perform the actions direct the operation of the computing system in response to having executed computer-executable instructions. An example of such an operation involves the manipulation of data. The computer-executable instructions (and the manipulated data) may be stored in the memory 104 of the computing system 100. Computing system 100 may also include a display 112 that may be used to provide various actual user interfaces, such as those described herein. Computing system 100 may also contain communication channels 108 that allow computing system 100 to communicate with other message processors, for example, over network 110.
As discussed in greater detail below, embodiments of the present invention may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory. Embodiments within the scope of the present invention also include physical computer-readable media and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. The computer-readable medium storing the computer-executable instructions is a physical storage medium. Computer-readable media carrying computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can include at least two distinct categories of computer-readable media: computer storage media and transmission media.
Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
A "network" is defined as one or more data links that allow electronic data to be transferred between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmission media can include a network and/or data links which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures may be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or a data link may be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like.
The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Fig. 2 abstractly illustrates a multi-document application 200. A computer program product, which may be comprised of one or more computer-readable media having computer-executable instructions thereon, may represent multi-document application 200. When executed, the computer-executable instructions implement a multi-document interface on a display (e.g., display 112 of FIG. 1). Thus, multi-document application 200 is illustrated as including multi-document interface 210. Multi-document interface 210 need not be the only interface provided by multi-document application 200. Furthermore, fig. 2 is only an abstract representation.
The multi-document application also includes a configuration interface 220 that permits a user to specify custom settings for the multi-document interface 210. In this abstract representation, there are six custom settings 221 through 226 configured by the user, but the ellipses 227 indicate that there may be more or less than six such custom settings set by the user. An example of custom settings for a multi-document interface that may be set by a user is described below. However, the principles described herein are not limited to the configuration arrangements described herein.
Fig. 3 abstractly illustrates a multi-document interface 300 representing an example of the multi-document interface 210 of fig. 2. The multi-document interface 300 includes a viewing area 310 and a tab group element 320. More specific examples of such a multi-document interface will be described with reference to the following figures. The viewing area 310 is configured to display one document at a time, even if multiple documents are open in the multi-document application. The tab group element 320 displays one or more tabs 321 to 323. Each tab includes a control that permits visualization of the respective document in the viewing area. For example, if tab 321 is selected, a particular document is visualized in display area 310. If tab 322 is selected, another particular document may be visualized in display area 310. If tab 323 is selected, a further specific document is visualized in the display area, and so on.
Ellipses 324 indicate that there may be any number of tabs, whether more or less than three, in the tab group element 320. Although the tab group element 320 is illustrated as being above the viewing area 310 in FIG. 3, FIG. 3 is merely an abstract representation of a multi-document interface. The principles described herein are not limited to the actual location of the tab set elements relative to the viewing area. Relative to the viewing area 310, the tab set element 320 may be above, below, to the left, to the right, or have any other orientation. In some embodiments described below, the location of the tab group element 320 may even be customizable by the user.
The principles described herein are not limited to documents of the type displayed in the viewing area 310. The document may be edited in the viewing area 310 or may be uneditable in the viewing area 310. The document may be any data visualization. Examples include graphical editors, Word documents, spreadsheets, flow charts, images, videos, or any other visualization of data. The document need not be of any particular file type, and different file types may be seen within the viewing area 310 by selecting the appropriate tab.
For some and potentially all of the documents opened by the multi-document application, the multi-document interface adds a new tab to the tab group element when a new document is opened. In one or more embodiments, when there is no space in the tab group element for a new tab to view, the multi-document interface hides at least one tab to make room for the new tab in the tab group element. In this case, the tab group element displays tabs corresponding to each of only a subset of the documents open in the multi-document application. In addition, the multi-document interface provides navigation controls for navigating the tabs to change which subset of tabs are displayed in the tab group element.
FIG. 4 illustrates an example user interface 400 that represents only one of an infinite number of variations of the multi-document interface 210 of FIG. 2. Tab group element 420 is displayed along the row above viewing area 410. In subsequent figures, while the tab group elements appear above the viewing area in each of the subsequent figures showing the multi-document interface, the tab group elements and viewing area will not be marked to simplify the schematic. In this case, six tabs 421 to 426 are visible, corresponding to the files solutionobserver.cs, solutionoptions manager.cs, utilitymethods.cs, menuitemtest.cs, packagettest.cs, and packagettest.cs. Any of these documents may be displayed in viewing area 410 by selecting the appropriate tab. There is a scroll indicator 431 (which is one example of a navigation control) and the scroll indicator 431 may be selected to scroll left in the tab list in the tab group element. Thus, in this case, while there are six tabs currently visible, the other tabs will be visualized by selecting the scroll indicator 431 so that they can be selected to display their corresponding documents. When scrolling to the left, there will be a tab on the right side of the list that becomes hidden, causing a right scroll indicator (not shown in FIG. 4) to appear.
As previously mentioned, there are many items on a configurable multi-document interface. Recall, therefore, that the multi-document application 200 of figure 2 includes a configuration interface 220. Fig. 5 shows an example of such a configuration interface 220.
FIG. 5 illustrates a configuration interface section 500 in which a user can manipulate a tab insertion and removal criteria section 510 (the tab insertion and removal criteria section 510 edits insertion and hiding criteria that decide which tabs to hide and how to insert tabs when there are too many tabs to view simultaneously in a tab group element), an ordering criteria section 520 that edits ordering criteria that decide how to order tabs in a tab group element, a tab resizing section 530 that allows the user to customize the resizing criteria of tabs and other specialized features, a close control setting 540 for selecting a close control where to place a tab, and a pinning tab section 550 that allows a pinned tab to be pinned in a separate row or column relative to an unpinned tab.
The tab insertion and removal criteria section 510 includes a "insert tab to the right" radio button 511 that, when selected, inserts a tab to the right of the previously existing rightmost tab. Otherwise, if radio button 511 is not selected, the new tab is inserted to the left. Radio buttons 512 and 513 relate to the removal or hiding of tabs when tab insertion results in too many tabs being simultaneously visible in a tab group element. If radio button 512 is selected, it causes the tabs to be removed in the insertion order. In other words, if one of the multiple tabs is to be hidden, then those tabs that were added to the tab group element earliest are selected for hiding. If radio button 513 is selected, it causes the tab to be removed according to the recency of use. For example, if one or more tabs are to be hidden, those tabs that are least recently used are selected for hiding.
Of course, configuration interface 500 is merely an example of configuration interface 220 of FIG. 2. The principles described herein are not limited to any particular hiding criteria for hiding tabs when there is not enough space for a tab group element to display all tabs simultaneously. Any such hidden criteria may be configured by the user in accordance with the broad principles described herein. In each case, once the tab is hidden, the appropriate navigation control of the tab group element may permit navigation back to the tab in order to blank the tab.
As an example, the tabs may be hidden according to some document hierarchy of the corresponding document, with the tab of the document having the lowest rating being hidden when the new tab requires the hiding of one or more other tabs.
The tab can be hidden according to the document editing time. The edit time can be a total edit time since the document was created, a total edit time since the tab was added to the tab group window, a total edit time within a particular time period (e.g., two hours), a total edit time by an individual logged into the multi-document application (in the case of a document with multiple authors), and so forth. Regardless of how the edit time is measured, the tab corresponding to the document with the least edit time may be hidden.
Similarly, the tab may be hidden according to the document viewing time. The view time may be a total view time since the document was created, a total view time since the tab was added to the tab group window, a total view time within a particular time period (e.g., two hours), a total view time by an individual logged into the multi-document application, and so forth. Regardless of how the viewing time is measured, the tab corresponding to the document with the least viewing time may be hidden.
The tabs may be hidden according to the access frequency of the corresponding document, which may be the number of times the document is accessed within a given time period (e.g., since the document was created, since it was last opened, or within a fixed time period, or a combination thereof), or the time between accesses, with a higher access frequency representing a smaller average time between accesses. When a new tab is added, those tabs corresponding to documents with less frequent access may be hidden first.
The tabs may be hidden according to the item identifier, some projects are more protected from hiding, and some projects are less protected from hiding.
It is also possible to hide tabs alphabetically, where titles with earlier alphabetic dictionary ordering are hidden first (or last).
The tabs may also be hidden according to file type, with some file types being more protected from hiding and some being less protected.
The hiding criteria may also take into account other parameters of the document and may include combinatorial logic that applies multiple parameters of the document.
The sort criteria section 520 includes a checkbox 521 that sorts the tabs alphabetically, when selected, to sort the still visible tabs alphabetically. The sort tabs by item checkbox 522, when selected, sorts the tabs by item identifier. Alphabetic sort drop down menu button 523 sorts the drop down menu alphabetically, which is used to select a document to open, thereby causing a new tab to appear in the tab group element and potentially causing the document to also open.
Again, the ranking criteria section 520 is merely an example of the types of ranking criteria that may be used to rank the tabs. The principles described herein are not limited to any particular tab ranking criteria. Any ranking criteria may be configured by the user in accordance with the broad principles described herein.
As an example, the tabs may be ranked according to some document ranking of the respective documents, where the tabs are ranked according to the document ranking.
The tabs may be ordered according to document editing time. The edit time may be a total edit time since the document was created, a total edit time since the tab was added to the tab group window, a total edit time within a particular time period (e.g., two hours), a total edit time by an individual logged into the multi-document application (in the case where the document has multiple authors), and so forth.
Similarly, the tabs may be ordered according to document view time. The view time may be a total view time since the document was created, a total view time since the tab was added to the tab group window, a total view time within a particular time period (e.g., two hours), a total view time by an individual logged into the multi-document application, and so forth.
The tabs may be ordered according to the access frequency of the respective document, which may be the number of times the document was accessed within a given time period (e.g., since the document was created, since it was last opened, or within a fixed time period, or a combination thereof), or the time between accesses, with a higher access frequency representing a smaller average time between accesses. When a new tab is added, those tabs corresponding to documents with less frequent access may be hidden first.
The tabs may also be ordered according to their order of insertion, or according to recency of use.
The tabs may also be ordered according to file type.
The ranking criteria may also take into account other parameters of the document and may include combinatorial logic that applies multiple parameters of the document.
The form and type of navigation controls may also be user configurable. As previously mentioned, when there are a certain number of documents open in a multi-document application, there may be too many tabs to display in a tab group element. In this case, the tab group element hides one or more tabs and only shows a subset of the tabs available in the tab group element. To allow navigation to the hidden tab, the tab group element includes a navigation control.
In FIG. 4, for example, a left scroll control 431 is shown that identifies a scroll navigation control, where scrolling causes one tab to be revealed at a time and one tab to be hidden at a time as the user scrolls. However, other types of navigation controls may be configured by the user. For example, a user may select a jump control in which the user jumps from a set of tabs to a different set of tabs. There may also be a resize control where navigation is achieved by a combination of making the tab smaller in size (manifested as a zoom-out operation and allowing a previously hidden tab to appear) and making the tab larger centered on the portion of interest (manifested as a zoom-in operation and focusing on a subset of the tab at or near the center of the portion of interest).
Another different customization point in the multi-document interface is the use of pinned tabs. Fig. 6 illustrates a flow chart of a method 600 for pinning a tab described herein. While displaying the plurality of tabs (act 601), the multi-document interface detects a user selection to pin the selected tab (act 602). The multi-document interface provides a pinning control that the user can activate to assign a pinned state to a selected tab. For example, the user may right-click or perform some other gesture with respect to the tab to thereby request that the tab be pinned.
In response to the request, the multi-document interface assigns a pinned state to the selected tab (act 603). The pinned state gives the selected tab higher protection against hiding when there are more tabs in the tab group element than can be simultaneously displayed in the tab group element. In one embodiment, the pinned state ensures that the corresponding tab is indeed protected from hiding.
Also, in response to the user requesting a pinned state, the multi-document application remains pinned (act 604) such that the pinned state can be subject to a shutdown and reload of the multi-document application. The tab also displays a visualization of the pinned state (act 605). Fig. 7 and 8 illustrate two examples of how the pinned state is visualized.
In the interface 700 of fig. 7, there are five tabs 701 through 705 corresponding to five documents. Since the rightmost tab is highlighted, the corresponding document will normally appear in the viewing area, but is not shown in FIG. 7 in order to simplify the drawing and avoid unnecessary distraction. Tabs 701 through 704 include pin indicators 711 through 714, respectively, that represent visual indicators that the respective tabs 701 through 704 are pinned. In this case, the multi-document interface protects such pinned tabs from being hidden when more tabs are added to the tab group element. In fig. 7, the pinned tabs are displayed in a separate area of the tab group element as compared to the non-pinned tabs. In this particular case, the particular region is to the left of all unpinned tabs.
In fig. 7, the pinned tabs are arranged in the same row as the unpinned tabs, and a separator visualization may appear between the pinned tab portion and the unpinned tab separator. This separator indicates the boundary between the pinned and unpinned tabs, giving the user a more intuitive understanding of which tabs are pinned and unpinned.
In another example, in interface 800 of FIG. 8, there are nine pins 801 through 809 corresponding to nine documents. Since the pin 801 is highlighted, the corresponding document will normally appear in the viewing area, but is not shown in FIG. 8. Tabs 801 include pin indicators 811-814, respectively, by 804, again representing visual indicators that the respective tabs 801-804 are pinned. When more tabs are added, tabs 801 and 804 are protected from hiding. In fig. 8, the pinned tabs are displayed in a separate area of the tab group element as compared to the non-pinned tabs. In this particular case, the particular region is above all of the unpinned tabs.
More generally, the tab set elements are aligned in a first direction (horizontal in FIG. 8) with the unpinned elements. The pinned element portions are also aligned in a first direction (horizontal in fig. 8), but stacked on the unpinned elements in a second direction (vertical in fig. 8). "stacked" in the vertical direction means that the unpinned portion is above or below the pinned portion. "stacked" in the horizontal direction (in this case, unpinned tabs in one column and pinned tabs in a separate column), the pinned tab column may be to the left or right of the unpinned tab column.
When a new unpinned tab is added to the unpinned tab area, the navigation control may appear to be associated with the unpinned tab portion, allowing navigation of the unpinned tab. However, the pinned tab is not hidden, and thus the pinned tab region does not require navigation controls.
Referring to FIG. 5, the user may use a check box 550 to configure how the pinned tabs are displayed. If the check box 550 is selected, the pinned tabs will be displayed in the older rows when displayed in the horizontal row (in the case of FIG. 8), or in separate columns if the tabs are displayed in a column. If the check box is not selected, the pinned tabs will be displayed in the same row (as in the case of FIG. 7) or in one column if the tabs are organized vertically.
In the embodiments illustrated in fig. 7 and 8, when the tab is pinned, the tab does not display less information about the corresponding document than before the tab was pinned. When a tab is created, the tab is annotated with sufficient information for the user to identify the corresponding document that would be displayed in the viewing area if the user selected the tab. For example, the information may include all or part of the title of the document. When the tab is pinned, the information remains in the tab. This is useful because it allows the tabs to be pinned without losing identifying information about the underlying document.
Referring back to FIG. 6, recall that the status of the tab pinned is saved. Thus, when the application is closed (act 606) and opened again (act 607), the pinned state of the pin is forced to remain (act 608).
The user may also configure various shading criteria for the multi-document interface. For example, fig. 9 illustrates a colored configuration interface 900 that includes five configuration settings 901-905. Configuration settings 901 are check box controls that, when selected, color the tabs by item identifier of the underlying document. In the user interface 400 of fig. 4, different colors (hereinafter, in black and white representation, different colors are represented by different hash marks or gray shades of tabs) represent different items. Here, the tabs 421 to 423 correspond to documents of one specific item represented by tabs having the same color. Tabs 424 and 425 correspond to a document of another specific item represented by those tabs having the same color as each other, which is a different item from the items of tabs 421 to 423, which is represented by the fact that tabs 424 and 425 have a different color from tabs 421 to 423. Finally, tab 426 has yet another different color, indicating that the tab corresponds to a different item than the items of the document represented by the other tabs 421 through 425. Fig. 10 illustrates a user interface 1000 in which colors that may be used to correspond to items may be customized by a user, or at least displayed to a user.
Referring back to FIG. 9, the tabs may also be configured by the file type of the corresponding document. This type of color coding and more complex configuration of color coding can be accomplished by allowing a user to configure shading by applying expressions to all or part of the file path and/or file name of the corresponding document. Selection of the check box 902 in fig. 9 allows this functionality. Upon selection of the check box 902, the user interface 1100 of FIG. 11 may appear. In the example of FIG. 11, the user has selected two expressions to apply to the tab. In the first expression, any tab representing a XAML document will be colored with the color FFFF0000 when applied. In the second expression, any tab that includes the phrase "[ design ]" in the title will be colored with the color FF0000FF when applied.
Fig. 12 illustrates the resulting application of color to the user interface 1200 after the expression is applied (temporarily ignoring window 1210, which is included later in the discussion of configuring the presets). Here, the tab group element 1200 includes tabs 1201 to 1204. Tab 1201 corresponds to an actively viewed document and is thus light colored. Tab 1202 does correspond to a XAML document and therefore receives the shading assigned by the first expression in fig. 11. Tab 1203 does correspond to a document in the title that includes the term "[ design ]", and thus will receive the coloring assigned by the second expression in fig. 11. Tab 1204 has a corresponding document that does not match any of the expressions of fig. 11, and thus receives a default coloring that applies to documents that are not actively viewed in the viewing area.
Referring back to FIG. 9, both checkboxes 901 and 902 may be activated simultaneously, in which case checkbox 903 may be used to allow the user to resolve the uncertainty as to whether the regular expression color should receive priority over the item color. If priority is given to the regular expression and the tab corresponds to a document that satisfies the shading expression, the color of the tab will be determined by the shading expression regardless of the item of the document. If priority is given to project coloring, the color of the tab will be determined by the project of the document if the document corresponds to the project, regardless of whether the document satisfies the expression.
Checkbox 904 forces the tab color to be a single tone with no intensity gradient. When the checkbox 904 is not selected, a drop down menu 905 activity is available and allows the user to select different gradients to apply to the tabs for a more customizable tab coloring.
Color coding may also be applied to the tab based on any other attribute or attributes of the tab. For example, colors may be applied according to the size of the document, recency of use of the corresponding document, or any other attribute previously described as having a potential impact on which tabs to hide, or the rank order of the tabs.
Other items may be configured by the user. Referring to fig. 5, a drop down menu 531 is provided to allow the user to customize the size of the tab group elements.
A drop down menu 532 is provided to allow the user to place tab group elements horizontally along the top or bottom of the viewing area in which the active document is displayed, or vertically along the left or right side of the viewing area.
A drop-down menu 533 is provided to allow the user to select which close controls should appear in the tab group element. For example, in one case, the user may select a close control that is made available in the tab group element. In this case, the user may rely on other close controls to control the currently active document. In another case, the user may choose to have the close control appear only in the tab corresponding to the active document. In this case, the user may close the active document by closing a close control in the active tab. For example, in FIG. 8, tab 801 is the active tab, and thus tab 801 is the only tab with close control 821. In another case, the user may choose to have the close control appear outside of any tab, but still associated with the tab group element. Referring to FIG. 7, a close control 722 may be used to close an active document. In another case, the user may select to have both the close control 722 and a close control that may be selected from within the active tab. In FIG. 7, for example, there is not only a close control 722 that is not attached to any particular tab, but also a separate close control 721 associated with the active tab 705. Thus, either can be used to close the document associated with the active tab 701.
The presence or absence of a file type icon indicator within the tab may also be configured by the user by selecting radio button 540. For example, in FIG. 7, file type indicators 731-735 appear in respective tabs 701-705, giving the user a visual indication of the file types of documents available.
The type of "dirty indicator" may also be configured by the user using a drop down menu 534. For example, in fig. 7, tabs 704 and 705 include respective dirty indicators 744 and 745. In this case, the dirty indicator is a red circle, but other preferences may be selected using the drop down menu 534. The dirty indicator may identify a document that already has edits that have not yet been saved.
The tab size of the tab may also be configurable by the user. The minimum tab size box 535 is used to select the minimum tab size and the maximum tab size box 536 is used to select the maximum tab size. Thus, even if the identification information appearing in the tab is much smaller than the minimum pixel size (20 pixels in the case of fig. 5), the tab will default to the minimum pixel size. Also, if the identification information to be presented in the tab is larger than the maximum size (220 pixels in the case of fig. 5), the tab will default to the maximum pixel size, resulting in some truncation of the identification information.
Thus, what has been described is a multi-document interface that is highly configurable by a user, with many possible configuration settings. To help manage configuration settings, the multi-document application also includes a configuration preset interface that allows a user to select preset options that automatically set the various custom settings provided by the configuration interface. Referring to fig. 12, a window 1210 is an example of such a preset interface. When a user selects a particular preset, a variety of underlying configuration settings are changed.
In one example, the preset option causes the multi-document interface to simulate an earlier version of the multi-document application.
In another example, there may be a preset option to restore the default settings for the current version of the multi-document application.
There may also be other custom settings provided to be pinned within the multi-document application (e.g., custom 1, custom 2, custom 3, and custom 4 in window 1210). The user may also customize the settings. For example, in FIG. 5, preset settings 541 "custom" allows a user to edit configuration settings. Drop down menu 541 may also be used to select any other preset, thereby allowing the user to see at least those other preset configuration settings.
Thus, a multi-document application is described that allows a high degree of user configurability, with a powerful management tool for managing the configuration of a multi-document interface.
The present invention may be embodied in other forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.