The present invention relates generally to graphical user interfaces for computer systems. More particularly, the present invention relates to systems and methods for interfacing applications and operating systems which provide for flexible customization of graphical user interfaces.
The evolution of the computer industry is 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""s many new I/O philosophies, such as xe2x80x9cuser friendlyxe2x80x9d, xe2x80x9cWYSIWYGxe2x80x9d and xe2x80x9cmenu drivenxe2x80x9d 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 these concepts was, and continues to be, the interface which allows the user to input commands and data and receive results, which is commonly refereed to as a graphical user interface (GUI).
One type of GUI display is based on a visual metaphor which uses a monitor screen as a work surface called a xe2x80x9cdesktopxe2x80x9d where documents are presented in relocatable regions termed xe2x80x9cwindowsxe2x80x9d. The user interacts with the computer by, for example, moving objects on the desktop, choosing commands from menus, and manipulating window controls, such as checkboxes 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 are one example of desktop objects which can be virtually any size, shape, or color. Some standard types of windows are commonly predefined for the interface including, for example, a document window and a dialog box. One example of a standard for a document window is illustrated in FIG. 2A. Each document window which conforms to this standard has a title bar with a title drawn in a system-defined font and color. Active document windows can also have controls as illustrated in FIG. 2A, for example, a close box, a zoom box, a size box, and scroll bars. These standard types of windows (as well as other standard desktop objects) are beyond the reach of users who wish to alter the appearance and/or behavior.
Accordingly, application developers can define their own nonstandard window types as desired, although each nonstandard window requires a relatively large block of memory. Further, even these nonstandard window types provide only limited flexibility and control over the appearance and behavior of desktop objects in that they are application-specific and do not present a consistent interface across all applications, i.e., if three different applications are running, each might present a different xe2x80x9clookxe2x80x9d on desktop. Once again, the user has no control over the appearance and/or behavior of these nonstandard window objects.
Since the window format, including the appearance, behavior and function of standard windows and window parts, is known a priori to applications which were designed for such conventional systems, these applications are written to take advantage of such knowledge. As seen in FIG. 3, suppose, for example that an application 10 desires to draw a rectangle in the color of the title bar beige, in this example) in a window (not shown on the desktop). The application assumes knowledge of the color of the title bar when using predefined standard window definitions 25 and, if this application uses window definitions created by the application itself, the application will have actual knowledge of colors defined by those windows. Accordingly, the application will simply send a command to the interface instructing that a beige rectangle be drawn in the window.
Each standard window, as well as any nonstandard window, conventionally has a corresponding window definition 25. The window definition 25 includes all of the data necessary to define the window. Looking at the active window illustrated in FIG. 1, data included in the window definition 25 for such an active window would include, for example, the size of the window, the relative location of the close box and zoom box in the upper lefthand and righthand corners, respectively, the number of parallel lines and their locations relative to the close box and the zoom box, and the upper boundary of the window and all of the other defining features of that particular window. The application supplies the variable parameters such as the location of the window on the desktop interface and, perhaps, the colors and/or fonts to be used for the text and/or figures in the window. As one can imagine, the window definitions can include a large amount of data and, therefore, can require a large amount of memory for each definition.
In addition to the amount of memory used to create non-standard window definitions, another problem with this conventional method of providing variety of appearance in the graphical user interface is the lack of a consistent apperance between objects drawn on the desktop by different applications. With multitasking i.e., multiple applications running simultaneously on a desktop, it is now common for users to simultaneously run multiple applications each of which has its own window on the desktop. However, if each application uses its own combination of standard and non-standard window definitions that result in each application having its own appearance and behavior. The dissimilarity in appearance and behavior between applications can be annoying and confusing to a user.
Accordingly, it would be desirable to allow application designers and application users to have additional flexibility and greater control over the appearance and behavior of desktop objects and individual controls for those objects.
According to exemplary embodiments of the present invention, an improved visual appearance can be provided to GUIs by providing an appearance management layer that gives users (both application developers and end users) the ability to customize the appearance and behavior of the desktop. This layer can be provided between all of the clients, e.g., applications, the end user, definition procedures, and the graphic subsystem which actually writes to the display. In this way, a level of abstraction is provided between the client and the system so that customization can be facilitated without requiring the client to have a detailed knowledge of the interface environment, which may be constantly changing.
Themes can be created which include sets of desktop objects that are designed, both in their visual appearance and behavior, to project an overall impression to the area. The user can switch between themes, even at runtime, to change this overall impression.