Conveying urgency via a control

[0002] The present invention relates to a desktop controller for an operating system adapted to convey a controls urgent need for attention and an interactive application cooperable with such an operating system.

[0003] Operating systems including graphical user interfaces (GUI) are well known. In such operating system, for example, Windows 95/98/NT produced by Microsoft Corporation, OS/2 produced by IBM or UNIX—interaction with a user is via a desktop.

[0004] A desktop controller/manager is a component of the operating system. This holds whether or not a browser-like application is accessible through the desktop or a browser is providing the desktop as is possible in operating systems such as Windows 98.

[0005] Typically a desktop controller for a GUI displays windows, icons, pull-down menus and a mouse pointer. In GUI operating systems the term control is used for any such object, including for example a button, that enables user interaction or input, usually for initiating an action, displaying information, or setting values.

[0006] If a fire monitoring system process owning a desktop control, for example a window, wants to draw attention to itself, it usually has only its own portion of a display to convey the urgency. It does not effect the whole desktop. Prior art solutions designed to increase a user's responsiveness to a control requiring urgent attention in an interactive application employ jangling music or flashing displays etc. These operations, however, may not be available on handheld monochromatic display devices or where the computer is without audio or tactile output.

[0007] Accordingly, the present invention provides a desktop manager for a multi-processing graphic user interface operating system operable to control the display of a plurality of controls each occupying respective display areas on a desktop, the desktop manager being characterised by means adapted to receive a request for urgency from a process owning a control; and means adapted to diminish the display of one or more of any other controls to draw the attention of a user to the control owned by the process requesting urgency.

[0008] In a further aspect there is provided an interactive application as claimed in claim 12 and a method as claimed in claim 16.

[0009] The present invention proposes that the control wanting attention requests the desktop manager—not itself—to vary and in particular diminish the display of other controls on the screen, thus drawing the user's attention to the control wanting attention. This variation of the display of the control relative to others signifies to the observer that the control wants some attention without relying on colour or sound effects.

[0010] Embodiments of the invention will now be described with reference to the accompanying drawings, in which:

[0011] FIG. 1 is a view of a desktop containing a number of windows; and

[0012] FIG. 2 is a view showing the z-order of controls on a portion of the desktop of FIG. 1.

[0013] Referring now to FIG. 1, a control, Window A, is owned by an alarm generating process. On the current desktop are a plurality of other controls: windows B, C and D. When an alarm goes off, it is desirable to draw the attention of the operator to window A in a visual fashion.

[0014] The invention enables the process owning window A to effect the pixels comprising the display of windows B, C and D. Thus, these latter relatively unimportant controls fade whilst the one requesting action gets bolder in comparison. It is this action upon other controls by the control requiring urgent attention that is the key to this invention.

[0015] This description largely employs an implementation independent terminology, which is applicable to Microsoft Operating Systems, UNIX, OS/2 or Java APIs. For more information on developing applications for Microsoft Windows, in particular, see “Windows API Bible”, James L. Conger, The Waite Group, 1992.

[0016] Programs—or more correctly, running processes request access to the desktop via a call to the desktop manager. This request returns a Window Handle which is then used by the process to draw on the screen.

[0017] The Window Handle itself is obtained by requesting the Desktop's Window to create another window within it. The Desktop Window Handle is obtained via an API call:

[0018] DesktopWinHandle=SystemGetDesktopwindowHandle( );

[0019] MywindowHandle=CreateWindow(DesktopWinHandle . . .) ;

[0020] The effect of this is two fold:

[0021] the Desktop creates a new Window Handle associated with a window to be contained within it; and

[0022] the Desktop process knows about the MyWindowHandle it gave out and to whom it gave the handle.

[0023] The Window Handle is used by a process as a container to hold items to be displayed. Each operation (like draw a line, insert text, show an image, repaint the window) requested by the process is sent to the desktop manager along with the relevant Window Handle. (In Object Oriented terminology, the object representing the desktop manager is sent a message requesting action on the associated object representing the Window Handle.) The desktop manager then does the relevant action for the requesting process.

[0024] If a third-party process wants to request a Window Handle owning process to alter its window, it sends a message to the owning process Message Dispatching loop the Window Handle is not accessed directly.

[0025] When a window for a process is activated, associated information is held by the desktop manager process, for example, visibility, position or modality. (When a modal dialog box is on the screen, the user cannot switch to another part of the program and also access is limited to other visible windows of the program that called the dialog box.) This information, in combination with information for all the other Window Handles, is then used to control the picture presented upon the display device (the screen).

[0026] The crucial thing to note is that it is the desktop manager that controls the display of the windows residing therein—these latter windows request a display, but it is the desktop manager that decides what portion of windows are to be shown. This is the reason why Windows can overlay each other without (in certain programming modes) the owning processes noticing.

[0027] The desktop manager is assumed to obey the commands of the process holding a Window Handle. Thus, if the owning process says paint a line Red from here to there, the desktop manager will paint a red line according to the requested co-ordinates (allowing for things like scaling and window dimensions/attributes). It will not draw a Blue line, nor turn a straight line into a curve, nor substitute dots for a continuous segment.

[0028] Some actions the desktop manager takes are notified to the owning process: things like window movement notifications are sent to the owning process—which does not have to take any notice of them. In general, the owning process assumes the desktop manager has not altered the display in its window without telling the owning process.

[0029] The preferred embodiment provides a set of operations which perform Window alteration without notification to a Window's owning process. Preventing notification should be done if a process wants to increase its relative visibility on the desktop without prompting or relying on other processes to re-paint themselves in response to the changes the desktop manager makes to their display.

[0030] The present embodiment provides a desktop controller including an API of the form:

[0031] RequestDesktopUrgency(DesktopWindowHandle,MyWindowHandle, Urgency)

[0032] where DesktopWindowHandle is the Window Handle of the Desktop (as defined above); MywindowHandle is the Window Handle of the Window whose relative visibility is to be altered (as defined above); and Urgency is an integer setting the degree of urgency, Urgency can have the following ranges of values:

[0033] <0−>decrease visibility

[0034] 0−>reset visibility

[0035] <0−>increase relative visibility

[0036] Providing the Urgency parameter allows for more than one request for urgency to be active, enabling the desktop manager to either decide to process all of them or decide which one is to take priority on the basis of Urgency or just process the latest request.

[0037] In a preferred embodiment, the relative increase in visibility is implemented by getting the desktop manager to remove pixels (depixelate) from all the other windows, so making the process requesting urgency more obvious to the user.

[0038] In a Microsoft Windows type embodiment, the invention can take advantage of the WM_SAVEBITS window property. If a process switches on this property, every time it re-paints its window, a copy of the re-painted image is saved by the desktop controller. Thus, if a window changes order with other controls on the desktop, the desktop controller does not need to ask the owning process to re-paint its window, rather it uses the bitmap it has stored in memory.

[0039] The desktop controller also knows the z-order of the saved window bitmaps in memory, as represented in FIG. 2. Thus, the controller knows that the background for point x in Window D, is the foreground for the same location in Window C. Similarly, the background for point x in Window C is the desktop wallpaper colour for this location. Thus, in the preferred embodiment a desktop controller is adapted to depixelate controls on the desktop by iterating through locations in saved control bitmaps to be depixelated from the bottom (desktop wallpaper) of the z-order to the top and setting the colour for each location to be depixelated to the colour of the control beneath it in the z-order.

[0040] It will be seen that this method of depixelation will cause upper windows in the z-order to diminish more slowly to the desktop wallpaper than lower windows. Thus, in a variation the desktop controller is adapted to set selected locations to either the foreground of one any controls requesting urgency or the desktop wallpaper whichever is higher in the z-order.

[0041] Thus, when a RequestDesktopUrgency message is received by the desktop manager from the process owning window A, it proceeds to delete pixels from all the other controls, in the case of FIG. 1 windows B, C and D. This means that pixels in the effected controls are set to the background colour of the control, that is the colour of the control underneath in the z-order.

[0042] It should be noted, however, that as window A is associated with the process requiring urgency, the background for the point y in window B, remains the foreground colour of the same location in window A, because window A, the window requesting urgency, is not being depixelated.

[0043] So, by iteratively setting the colour for each pixel to its background colour for each affected control on the desktop, these pixels will take the colour of the desktop wallpaper, thus causing these controls to disappear and highlight the control for the process requiring urgency.

[0044] Using this technique, the processes owning these effected controls are not told that their picture has been corrupted. This pixel deletion continues until the control which is being made relatively more important is selected.

[0045] If more than one request for urgency is received at any given time, one option available to the controller is not to delete pixels from any urgent windows. Alternatively, the rate of depixelation can be varied so that none takes place on the most urgent window, some on less urgent windows and most on non-urgency requesting windows.

[0046] Once the urgent request has been satisfied, for example by selecting the requesting window, the desktop can be restored by the desktop requesting each owning process to re-paint, which in turn causes the saved bitmaps to be re-freshed.

[0047] The desktop manager also needs to keep track of the level of depixelation for effected controls so that, if these windows are altered (or repainted), for example by moving the window or by its owning process updating the window contents, the desktop manager can return these windows to their previous state of depixelation. Thus, if an affected window is moved, the desktop manager can begin by requesting a window to re-paint, thus re-freshing the saved bitmap, and immediately depixelating the saved window to the stored level, to maintain the relative unimportance of these effected windows. The desktop manager then iteratively continues to depixelate the saved bitmaps as before.

[0048] When the Window which is requesting relative Urgency is selected (by Mouse or Keyboard or Voice etc.), the desktop manager cancels the Urgency request and restores all depixelated windows to their correct displays. Thus, the desktop manager alters the relative importance of Windows by pixel stealing.

[0049] In order for the first embodiment to work, applications either need to be forced to turn the WM_SAVEBITS window property on, or the desktop needs to be adapted to cause all windows to turn this property on, as soon as it receives a first request for urgency. If saving memory is a high priority, owning processes can then be allowed to turn off the WM_SAVEBITS property when no urgency requests are active.

[0050] In an alternative embodiment, when the RequestDesktopUrgency message is received by the desktop manager, it proceeds to iteratively reduce the size of the other controls.

[0051] In the case of windows, the desktop manager needs to re-size window frames surrounding a window rather than effect the contents of the window client area as in the case of the first embodiment.

[0052] It should be noted, however, that while the first embodiment should work with most controls, some controls do not lend themselves to being re-sized freely. If in the second embodiment, the desktop manager issues successive commands requesting owning processes to set their size to ever smaller dimensions, some may refuse and thus the impact of a process, request for urgency may be lost. On the other hand if the desktop manager does not notify affected processes, rather sets their control size directly, this may cause some processes to crash.

[0053] Some operating systems are easily adapted to employ the second embodiment. In UNIX operating systems, it is possible for the desktop controller to cause a window to be re-sized without the owning process being notified. In Microsoft Windows operating systems, however, it is easier to adapt the desktop controller to implement the invention, simply by having it request process owning controls to re-size. If some processes refuse to re-size their controls, then the effect of the invention will be diminished.

[0054] In the alternative embodiment, simultaneous requests for urgency can be dealt with in an analogous manner to those of the first embodiment. If an Urgency parameter is used in the RequestDesktopUrgency API, the desktop manager can also decide to reduce the size of controls at a rate inversely proportional to their level of urgency. Thus, the most urgent control will not be reduced, while the least urgent control would be reduced at a rate only slightly slower than controls not requesting urgency. When the most urgent control is dealt with, the desktop manager then restores the size of the next most urgent control until all urgent requests are dealt with.

[0055] It will be seen that a user returning to use a computer where an application has issued a request for urgency may be surprised to see that only one desktop control remains on the desktop. This should be taken into account by applications and processes employing the invention, so that they advise the user accordingly.

[0056] The present description referred to a fire alarm. It will be seen, however, that the invention is applicable to any type of process which may want to request attention from a user. For example, if an e-mail program receives a message marked urgent as distinct from normal priority, it may want to notify the user, or if a computer is connected to a phone system, then it may want to advise a user that a voice mail message has arrived.