A visual display such as a graphical user interface like a “desktop” display presented by software typically includes objects and containers. An object can be any item on a visual display. A container can be an object upon or within which other objects are presented. For example, a container, such as a spreadsheet or word processing document in a window, or a particular icon, may include a number of objects, such as cells, graphics, user interface elements, and others. The objects within such a container may have a defined presentation size, position, etc. on the display screen.
Typically, a body of code within the specific application is responsible for arranging elements of a visual display such as objects and containers. For example, an application program presenting a number of objects includes code representing a layout editor, sometimes referred to as a “form editor” or “2D editor,” for arranging and/or editing the appearance of the containers and objects presented by that application. However, to function properly, the layout editor requires specific, prior knowledge of the parent container for the objects to be edited. In addition, a user input device, such as a mouse pointer, is typically positioned over the container and clicked in order to perform a function on the object. Thus there needs to be a one to one correspondence between the absolute position of the pointer and the position of the object in the container for the indicated operation to convey the correct command or information.
Currently, applications send image and object and container data directly to a video display screen in a streaming fashion. If a developer wants to change or transform the object in any way there is no way to intercept the stream going from the application directly to the screen. Thus any manipulation requires the developer to go into the code of the application itself in order to modify or transform the presentation of the object or the container in any way. This is a code intensive operation and application specific, with each such iteration requiring a substantial expenditure of time and effort, with the result not being transferable to other applications or platforms.
In an operating system such as Microsoft's Windows XP® operating system, for example, the window manager directs application content directly to the display screen. Thus there is no way for a developer who desires to perform some manipulation on the content, or add an effect to the display content, cannot modify it because the window content is not stored anywhere. The application simply takes a stream of data and sends it to the screen.
A desktop “compositor” engine (DCE) has been developed to facilitate redirection of the content of the current application window stream to an intermediate off screen location prior to sending it to the display screen. This facilitates manipulation of the window content, which can then be transformed and then transmitted to the screen or simply passed through if no transformation is being performed.
However a difficulty arises when a user is to interact with an object on the transformed display screen. For example, assume that an object like a square figure is transformed to a circular shape and repositioned from an x,y absolute position to an x+a, y+b actual position on the display. If a user then positions his input device, e.g. a mouse pointer over the image now displayed at x+a, y+b and clicks on the image, the command will not be received, since the pointer is not over the position that corresponds to the application's object.
For the layout editor conventionally to have such specific knowledge of the parent container and change properties of the container and objects within that container based on that knowledge and the editing operation, the layout editor of the application consists of extensive code. Further complicating matters, an object may be placed in an arbitrary location in a container that may arbitrarily arrange its children. Also, resizing the object may adversely affect the arrangement of the children as well as the parent container itself. Therefore, the changes made by the layout editor may be ineffective.
As such, there is currently no simple manner in which an application interface may resize, re-arrange or otherwise transform windows or objects in windows on a display without application specific code specific to each application. Further, if an application is unaware of an existing mechanism for supporting a transformation such as supporting High dots per inch (DPI) display, the application will not be able to properly display in a High DPI window. It is with respect to these considerations and others that the present invention has been made.