Patent Application
20120159363
The subject disclosure relates to computing system display management, and, more specifically, to establishing rules that facilitate visibility control for graphical items associated with a computing display.
Computing systems utilize various output mechanisms to relay information to system users. For example, computing systems utilize display screens to render graphical elements, such as windows, text, buttons and/or other control elements, etc., for visualization of the graphical elements by a user. Conventionally, graphical elements such as windows are configured with a set of coordinates (e.g., x and y coordinates) that specify an area of the display at which the elements are to be displayed. In addition, windows and other graphical elements are conventionally managed by a z-order stack and/or other similar mechanisms that control the order in which graphics are displayed in the event of an overlap. For example, if two windows occupy a common area in two-dimensional display space, the z-order stack can be used to determine which window is displayed in front of the other window, thereby making the topmost window visible and the bottommost window invisible at the point of overlap.
In traditional display management systems, windows share the same z-order stack. However, this single stack poses difficulties when multiple windows or other graphical elements desire to be at the top of the z-order due to contention between the graphical elements for the top position of the stack. In addition, conventional display management mechanisms provide no means by which relative z-order positioning can be maintained for different windows or other graphics, as graphical elements are free to move within the single stack. Further, the lack of z-order control in conventional systems results in significant difficulty in protecting portions of user experience as well as applying windowing rules to subsets of windows. Accordingly, it would be desirable to implement display management systems that provide improved z-order control.
The above-described deficiencies of today's computing system and resource management techniques are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.
A simplified summary is provided herein to help enable a basic or general understanding of various aspects of exemplary, non-limiting embodiments that follow in the more detailed description and the accompanying drawings. This summary is not intended, however, as an extensive or exhaustive overview. Instead, the sole purpose of this summary is to present some concepts related to some exemplary non-limiting embodiments in a simplified form as a prelude to the more detailed description of the various embodiments that follow.
In one or more embodiments, windows and other display elements are managed via multiple z-order stacks. Respective sets of one or more z-order stacks, referred to herein as z-order bands, are utilized to arrange windows and other graphics corresponding to respective application types. In addition, the display management system controls which windows and/or other graphical elements can enter and exit each band. In one example, graphical elements within a given band can additionally be subject to per-band properties, such as windowing rules, format properties, etc., corresponding to the band. Additionally or alternatively, assignment of graphics to z-order bands and/or configuration of graphics within z-order bands can be controlled based at least in part on user input.
In other embodiments herein, z-order bands and/or other suitable mechanisms are utilized to facilitate registration watermarking for a computing environment. One or more licensed elements of a computing environment, such as applications, an operating system, etc., can utilize a license registration process by which the license(s) corresponding to the licensed elements of the computing environment are verified and/or otherwise registered. In addition, the computing environment can manage the rendering of windows and/or other display elements as generally described above. Upon determining that the licensed elements of the computing environment have not been successfully registered (e.g., upon fulfillment of other conditions, such as the passage of a predetermined amount of time, etc.), the computing system renders a registration watermark display on the display screen. The registration watermark display is assigned a z-order band that enables its display over all other graphical elements associated with the computing system. In addition, the computing system prevents any other graphical elements from entering the z-order band associated with the registration watermark display and interfering with its visibility.
These and other embodiments are described in more detail below.
Various non-limiting embodiments are further described with reference to the accompanying drawings in which:
By way of introduction, computing systems render graphical items such as windows, text, buttons and/or other control elements, etc., on display screens and/or other display devices. Windows and other graphics are configured with (x, y) coordinates and/or other means to specify their occupied display area. In addition, a window and/or other graphical item is further configured with one or more parameters that determine whether the graphical item is to be displayed in front of or behind other graphical items, e.g., defining the z-dimensional order (or z-order) of the graphical item. For example, in the event that two windows overlap, the z-order of the windows is utilized to determine which window is displayed in front of the other.
Conventionally, windows in a computing environment utilize a common z-order stack. However, this results in contention between windows for the top position in the stack. In addition, a single-stack configuration provides no means by which relative z-order positioning can be maintained for different windows or other graphics, as windows and other graphics are free to move within the single stack. Further, use of a single z-order stack results in difficulty in protecting specific parts of the overall user experience portions as well as applying windowing rules to subsets of windows.
In view of at least the above shortcomings of conventional display management systems, windows and other display elements are managed in accordance with various embodiments herein via the use of z-order bands, which enable separation of z-order into multiple z-order stacks. In one example, z-order bands are utilized to arrange windows and other graphics corresponding to respective applications and/or application technologies (e.g., accessibility, media playback, word processing, etc.). A policy engine and/or other mechanisms are utilized to control entry into each band and/or movement between bands, thereby reducing contention between windows for z-order position within a z-order band and improving user experience. Further, as z-order bands can be utilized to separate application technologies, contention between applications of respective technologies for position within z-order is mitigated, thereby increasing system performance.
In some embodiments herein, z-order bands can be associated with various properties, which can in turn be utilized by windows and/or other graphics assigned to the bands. For example, windows and other graphics associated with a z-order band can be given display properties such as windowing rules, format properties, or the like, that correspond to the band. In another example, per-band ordering rules are implemented to provide further granularity for z-order control within a specific band. In further examples provided herein, operations such as assignment of graphics to z-order bands, configuration of graphics within z-order bands, or the like, can be performed based at least in part on user preferences and/or other user input. In still other examples provided herein, z-order bands utilize a modular structure that enables addition, removal, and/or reordering of bands and/or other suitable operations.
In other embodiments described herein, license registration watermarking for a computing environment is enabled through the use of z-order bands or other suitable mechanisms. In the event that one or more licensed elements of a computing environment, such as applications, an operating system, etc., utilize a license registration process by which the license(s) corresponding to the licensed elements of the computing environment are verified, activated, and/or otherwise registered, the computing system can verify that the license(s) have been successfully registered. In response to determining that the licensed elements of the computing environment have not been successfully registered (e.g., upon fulfillment of other conditions, such as the passage of a predetermined amount of time, etc.), a registration watermark display is rendered on the display screen. The registration watermark display is assigned a z-order band that enables its display over all other graphical elements associated with the computing system. In addition, the computing system prevents any other graphical elements from entering the z-order band associated with the registration watermark display and interfering with its visibility. In one example, the registration watermark display can be utilized to obscure other graphics associated with the computing system, thereby preventing unauthorized or unlicensed use of the licensed elements of the computing system.
By utilizing z-order bands as generally described herein, respective portions of user experience can be protected. For example, by having different bands for different application types, windows of a first application type can be configured such that they can never intrude on top of windows of a second application type. Further, bands can be used to keep windows in a relative position to other windows. For instance, bands can be used to ensure that accessibility windows are displayed on top of all other windows in the system. Additionally or alternatively, separate bands can be used for different technologies, enabling addition and/or removal of technologies via their corresponding bands with minimal impact to other technologies as well as facilitating different treatment of windows and/or other graphics corresponding to different technologies. In another example, bands can be used to provide a mechanism to apply and enforce behavior for a set of windows and/or other graphics. For example, a band can be configured to ensure that all windows and/or other graphics within the band adhere to specific style guidelines, window size and position guidelines, or the like.
In one embodiment, a graphical display management system as described herein includes a band management component configured to define a set of z-order bands, to associate relative z-order ranges with z-order bands of the set of z-order bands, to assign display elements to respective z-order bands of the set of z-order bands, and to generate a linear order of the z-order bands such that first display elements assigned to a first z-order band of the set of z-order bands associated with a first z-order range are displayed in front of display elements assigned to a second z-order band of the set of z-order bands associated with a second z-order range that is deeper than the first z-order range. The system further includes a display component configured to render the display elements according to the linear order of the z-order bands.
In one example, the z-order bands respectively correspond to application types. In other examples, the band management component includes a policy engine component configured to maintain a set of policies utilized by the band management component to assign the display elements to the respective z-order bands of the set of z-order bands. The policy engine component can be further configured to maintain a set of entrance policies and a set of exit policies that respectively control entry and exit of the display elements into respective z-order bands of the set of z-order bands. Additionally or alternatively, the policy engine component can be configured to maintain a set of enforcement policies that control movement of the display elements between z-order bands of the set of z-order bands.
In some implementations, respective z-order bands are configured with display properties, and the display component is further configured to render the display elements according to the display properties with which their respectively assigned z-order bands are configured. The display properties can include, e.g., display format properties, windowing rules, full-screen display properties, or graphical element sizes. In another example, the band management component is further configured to assign the display elements to the respective z-order bands of the set of z-order bands based at least in part on user preferences.
In further implementations, the band management component includes a band creation component configured to create at least one z-order band, to assign the at least one z-order band to at least one corresponding z-order range, and to associate the at least one z-order band with the set of z-order bands. Additionally or alternatively, the band management component can include a band reordering component configured to alter the z-order ranges with which respective z-order bands of the set of z-order bands are associated. In one example, the band reordering component can be further configured to alter the z-order ranges with which respective z-order bands of the set of z-order bands are associated based at least in part on user input.
In additional implementations, the system can further include a per-band ordering component configured to associate z-order positions with display elements assigned to a z-order band of the set of z-order bands. Accordingly, the display component can be further configured to render the display elements assigned to the z-order band of the set of z-order bands according to respective z-order positions such that display elements associated with a first z-order position are displayed in front of display elements assigned to a second z-order position that is deeper than the first z-order position.
In still other implementations, the system can include a registration component configured to facilitate registration of a computing environment associated with the display elements. In such an example, the band management component can be further configured to generate an unregistered display band and associate an unregistered graphical display with the unregistered display band if the computing environment associated with the system has not been registered by the registration component. Further, the display component can be further configured to render the unregistered graphical display associated with the unregistered display band in front of the display elements if the computing environment associated with the system has not been registered by the registration component.
In another embodiment, a method for managing a computer display includes associating a set of z-order display bands with respective depth ranges and application types, assigning graphical elements to respective z-order display bands according to application types associated with the graphical elements, ordering the z-order display bands such that a first set of graphical elements assigned to a first z-order display band associated with a first depth range are displayed over a second set of graphical elements assigned to a second z-order display band associated with a second depth range that is z-dimensionally deeper than the first depth range, and displaying the graphical elements according to the ordering.
In one example, the graphical elements are assigned to the respective z-order display bands of the set of z-order display bands based at least in part on a set of band management policies. For example, the assigning can include controlling entry of graphical elements into the respective z-order display bands based at least in part on a set of band entrance policies, controlling exit of graphical elements into the respective z-order display bands of the set of z-order display bands based at least in part on a set of band exit policies, and/or controlling movement of graphical elements between z-order display bands based at least in part on a set of band enforcement policies.
In another example, the method can additionally include associating z-order display bands with respective display properties that include, e.g., display format properties, windowing rules, full-screen display properties, and/or graphical element sizes. The graphical elements are then displayed according to the display properties associated with the z-order display bands to which the graphical elements are assigned. In a further example, graphical elements are assigned to respective z-order display bands based at least in part on user preferences.
In a further example, the method additionally includes modifying the set of z-order display bands via at least one of adding one or more z-order display bands to the set of z-order display bands, removing one or more z-order display bands from the set of z-order display bands, combining one or more z-order display bands of the set of z-order display bands, or reordering depth ranges associated with one or more z-order display bands of the set of z-order display bands.
In an additional embodiment, a system that facilitates graphical display includes a registration component configured to facilitate registration of a license for at least one licensed element of a computing system. The system further includes a band management component configured to associate a registration display with a registration display band and to associate respective graphics of the computing system with at least one system display band. The system additionally includes a display component configured to render the respective graphics and, if the license has not been registered via the registration component, to render the registration display associated with the registration display band in front of the respective graphics and to prevent the respective graphics from being moved in front of the registration display.
Herein, an overview of some of the embodiments for achieving computing system display management has been presented above. As a roadmap for what follows next, various exemplary, non-limiting embodiments and features for distributed transaction management are described in more detail. Then, some non-limiting implementations and examples are given for additional illustration, followed by representative network and computing environments in which such embodiments and/or features can be implemented.
By way of further description with respect to one or more non-limiting ways to conduct z-order management, a block diagram of an exemplary display management system is illustrated generally by
Conventionally, all windows and/or other graphics share the same z-order stack. However, as noted above, use of a single stack presents difficulties resulting from graphical items contending for the top position of the stack. As further noted above, there is conventionally no way to maintain relative z-order positioning of different graphical items, as the graphical items are free to move around in the single stack. As additionally noted above, there is conventionally no readily available manner in which windowing rules can be applied to subsets of windows.
Accordingly, the system illustrated by
In an embodiment, z-order bands as described herein can be utilized to provide additional functionality to a display window hierarchy. For example,
In one example, respective windows associated with a display environment can leverage relative window ordering to set the respective positions of the windows in z-order. For example, as shown in
In conventional display management systems, no mechanisms are provided to prevent windows from associating with the top-most window style. Accordingly, windows in conventional display management systems contend for top position in the z-order stack, which may in some cases result in undesired windows interfering with a desired topmost window. Accordingly, a display management system as described herein can employ z-order bands to group windows according to their application types. An example of sorting that can be facilitated via the use of z-order bands is illustrated by
In an embodiment, a display management system employing z-order bands can implement one or more policies that enforce entry of windows 400-420 into respective z-order bands and/or movement of windows 400-420 between z-order bands, thereby creating concretely defined z-order ranges for windows of different application types. In another example, windows and/or other graphics within a given z-order band can be ordered according to any suitable mechanism(s). For example, the top-most window style described above can be applied to one or more z-order bands, as shown by topmost window 410 and standard window 400 corresponding to application type C. In another example illustrated by
Turning next to
As shown in
As further illustrated in
Additionally or alternatively, band management component 600 can operate according to a default ordering to protect display items of one or more application types or technologies from interference from display items of other application types or technologies. In one example, user preferences 616 can facilitate complete or partial modification of the default ordering.
As further shown by
As described herein, z-order bands can be utilized to enforce policy for respective positions in a z-order stack. For example, diagram 700 in
As further described herein, z-order bands can also be utilized to effectively establish priorities for the display of items corresponding to different application types. For example, as shown by diagram 800 in
Turning next to
In another embodiment, further ordering granularity can be provided within one or more z-order bands. For example, as shown by
In a further embodiment, z-order bands as described herein can further be utilized to provide license registration watermarking functionality. For example, as illustrated by
In an embodiment, band management component 1100 can maintain a registration watermark display on a registration display band 1112. The registration watermark display can include, e.g., instructions or other information for registering the licensed computing system element(s) and/or any other suitable information or graphical items. Upon determining that the licensed elements of the computing environment have not been successfully registered (e.g., upon fulfillment of other conditions, such as the passage of a predetermined amount of time, etc.), band management component 1110 can provide the display associated with the registration display band 1112 along with other display elements on one or more system display bands 1114 to a display component 1120 for rendering.
The registration display band 1112 is configured such that its display is enabled over all display elements associated with system display bands 1114. In addition, band management component 1110 can be configured to prevent (e.g., via a policy engine component and/or any other suitable mechanisms) any other display elements from entering registration display band 1112 and interfering with its visibility. In one example, upon registration of the licensed element(s) of the computing system, registration display band 1112 can be disabled such that the registration watermark display no longer interferes with the visibility of system display bands 1114.
One of ordinary skill in the art can appreciate that the various embodiments of the display management systems and methods described herein can be implemented in connection with any computer or other client or server device, which can be deployed as part of a computer network or in a distributed computing environment. In this regard, the various embodiments described herein can be implemented in any computer system or environment having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units. This includes, but is not limited to, an environment with server computers and client computers deployed in a network environment or a distributed computing environment, having remote or local storage.
Distributed computing provides sharing of computer resources and services by communicative exchange among computing devices and systems. These resources and services include the exchange of information, cache storage and disk storage for objects, such as files. These resources and services also include the sharing of processing power across multiple processing units for load balancing, expansion of resources, specialization of processing, and the like. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may participate in the display management mechanisms as described for various embodiments of the subject disclosure.
Each computing object 1410, 1412, etc. and computing objects or devices 1420, 1422, 1424, 1426, 1428, etc. can communicate with one or more other computing objects 1410, 1412, etc. and computing objects or devices 1420, 1422, 1424, 1426, 1428, etc. by way of the communications network 1440, either directly or indirectly. Even though illustrated as a single element in
There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems can be connected together by wired or wireless systems, by local networks or widely distributed networks. Currently, many networks are coupled to the Internet, which provides an infrastructure for widely distributed computing and encompasses many different networks, though any network infrastructure can be used for exemplary communications made incident to the display management systems as described in various embodiments.
Thus, a host of network topologies and network infrastructures, such as client/server, peer-to-peer, or hybrid architectures, can be utilized. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. A client can be a process, i.e., roughly a set of instructions or tasks, that requests a service provided by another program or process. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself.
In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer, e.g., a server. In the illustration of
A server is typically a remote computer system accessible over a remote or local network, such as the Internet or wireless network infrastructures. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server. Any software objects utilized pursuant to the techniques described herein can be provided standalone, or distributed across multiple computing devices or objects.
In a network environment in which the communications network 1440 or bus is the Internet, for example, the computing objects 1410, 1412, etc. can be Web servers with which other computing objects or devices 1420, 1422, 1424, 1426, 1428, etc. communicate via any of a number of known protocols, such as the hypertext transfer protocol (HTTP). Computing objects 1410, 1412, etc. acting as servers may also serve as clients, e.g., computing objects or devices 1420, 1422, 1424, 1426, 1428, etc., as may be characteristic of a distributed computing environment.
As mentioned, advantageously, the techniques described herein can be applied to any device where it is desirable to perform display management in a computing system. It can be understood, therefore, that handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the various embodiments, i.e., anywhere that a computing system display device may be utilized. Accordingly, the below general purpose remote computer described below in
Although not required, embodiments can partly be implemented via an operating system, for use by a developer of services for a device or object, and/or included within application software that operates to perform one or more functional aspects of the various embodiments described herein. Software may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Those skilled in the art will appreciate that computer systems have a variety of configurations and protocols that can be used to communicate data, and thus, no particular configuration or protocol should be considered limiting.
With reference to
Computer 1510 typically includes a variety of computer readable media and can be any available media that can be accessed by computer 1510. The system memory 1530 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). By way of example, and not limitation, system memory 1530 may also include an operating system, application programs, other program modules, and program data.
A user can enter commands and information into the computer 1510 through input devices 1540. A monitor or other type of display device is also connected to the system bus 1522 via an interface, such as output interface 1550. In addition to a monitor, computers can also include other peripheral output devices such as speakers and a printer, which may be connected through output interface 1550.
The computer 1510 may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote computer 1570. The remote computer 1570 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 1510. The logical connections depicted in
As mentioned above, while exemplary embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system in which it is desirable to improve user experience with respect to a computing system display.
Also, there are multiple ways to implement the same or similar functionality, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software object, etc. which enables applications and services to take advantage of the techniques provided herein. Thus, embodiments herein are contemplated from the standpoint of an API (or other software object), as well as from a software or hardware object that implements one or more embodiments as described herein. Thus, various embodiments described herein can have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.
The word “exemplary” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used, for the avoidance of doubt, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.
As mentioned, the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. As used herein, the terms “component,” “system” and the like are likewise intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
The aforementioned systems have been described with respect to interaction between several components. It can be appreciated that such systems and components can include those components or specified sub-components, some of the specified components or sub-components, and/or additional components, and according to various permutations and combinations of the foregoing. Sub-components can also be implemented as components communicatively coupled to other components rather than included within parent components (hierarchical). Additionally, it can be noted that one or more components may be combined into a single component providing aggregate functionality or divided into several separate sub-components, and that any one or more middle layers, such as a management layer, may be provided to communicatively couple to such sub-components in order to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein but generally known by those of skill in the art.
In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the described subject matter can also be appreciated with reference to the flowcharts of the various figures. While for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the various embodiments are not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Where non-sequential, or branched, flow is illustrated via flowchart, it can be appreciated that various other branches, flow paths, and orders of the blocks, may be implemented which achieve the same or a similar result. Moreover, not all illustrated blocks may be required to implement the methodologies described hereinafter.
In addition to the various embodiments described herein, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiment(s) for performing the same or equivalent function of the corresponding embodiment(s) without deviating therefrom. Still further, multiple processing chips or multiple devices can share the performance of one or more functions described herein, and similarly, storage can be effected across a plurality of devices. Accordingly, the invention should not be limited to any single embodiment, but rather should be construed in breadth, spirit and scope in accordance with the appended claims.
