Method for enabling adaptive sizing of display elements

[0002] This application is related to a concurrently filed application Ser. No. 09/290,165, entitled “Method for Arranging Display Elements,” filed by D. Lovell and R. Thompson and assigned to a common assignee, the subject matter of which is incorporated herein by reference.

[0003] 1. Field of the Invention

[0004] The present invention generally relates to the design of adaptive computer display layout managers and, more particularly, to a method for designing and utilizing display elements that allows a layout manager to arrange and pack display elements to improve screen appearance, especially when displaying the components on a screen of unknown size.

[0005] 2. Background Description

[0006] The invention is an innovation in the design of “layout managers.” Layout managers are computing tools for arranging “elements” in a computer display. Elements are pictures, buttons, blocks of text, or other graphics which may be passive or active. Passive elements are for viewing only. Active elements may cause a change in appearance or behavior when stimulated by the action of a person viewing the display. These are the fundamental, abstract components of every display-based human-computer interface.

[0007] Layout managers function by finding the size of the elements of the display and positioning them according to a predetermined method. Some layout managers align their elements in a row or a column. Others assign elements to a predetermined areas, such as the top, bottom, left, right, or center.

[0008] When a layout manager arranges elements, it often creates areas not occupied by any element. This is especially true if the elements are not uniform in size. Layout managers will typically enlarge elements in one dimension to fill the unused areas. A layout manager which places a narrow element above a wide element might make the narrow element wider to keep the elements uniform in width. That action may leave the narrow element with more height than it requires.

[0009] To illustrate the problem, consider the following. We have a title element whose content is “AutoLoan Exchange.” The element preferably stacks the words “AutoLoan” above the word “Exchange.” It is eight characters wide and two lines high. A layout manager assigns a wider, thirty-character width. Now, the entire title fits on one line, but the element height remains at two lines.

[0010] Poor packing of display elements gives a poor aesthetic impression, wastes space available on the screen, and impairs understanding of the interface. Accordingly, authors invest a large amount of time hand crafting the layout of each screen in an application, at high cost per screen.

[0011] It is therefore an object of the invention to provide a layout manager to automatically adapt to changes in the size of the display and achieve an aesthetically pleasing appearance.

[0012] According to the invention, elements which are specially designed to answer element size queries enable an enhanced layout manager to pack elements on the display with greater uniformity and density than is possible with the element size queries available in the state of the art. The invention uses height-for-width and/or width-for-height trade-offs to allow the optimal resizing of said elements.

[0013] A layout manager determines the size of elements to be displayed by querying the elements. Prior art has established three queries by which a layout manager determines the size of each element. These are the element minimum, maximum, and preferred size in height and width. We add two additional preferred size queries: “preferred height given width” and “preferred width given height.”

[0014] A layout manager may now adjust the width of an element and, at the same time, revise its height. A layout manager may also adjust the height of an element, and, at the same time, revise its width. A layout manager which takes advantage of this capability is described in concurrently filed, copending application Ser. No. 09/290,165.

[0015] The queries in the state of the art do not relate preferred width to preferred height. This means that elements cannot adjust their size preferences based on a width or a height afforded them. An element which contains flowed text, for example, may become shorter when made wider.

[0016] When identified, the problem may be solved by manually overriding the preferred size answer of the element or by substituting another element with different behavior. The present invention enables the layout manager to automatically adapt without manual intervention. The adaption helps eliminate the need to tailor layouts according to their content. It enables a single application to work well with a variety of display sizes.

[0017] It is another object of the invention for the newly designed elements to function with layout managers that use only the queries existing in the prior art, i.e., maximum, minimum and preferred size queries, thus being backwardly compatible.

[0018] The invention is useful where a layout must adapt to the display of many different devices. Personal Information Devices (PIDs), for example, have displays which vary greatly in size and in aspect ratio. A designer creating an application for PIDs has no opportunity to hand-craft the screens for each display. Only an automatic method, as provided by the invention, will solve the problems which occur as the size of the target display area changes.

[0019] The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

[0020] FIG. 1 is a diagram representing the element size queries available in the state of the art;

[0021] FIG. 2 is an illustration showing an example of the preferred size of a wide or short element containing text;

[0022] FIG. 3 is an illustration showing the preferred size of a narrower or taller element containing the same text as in FIG. 2;

[0023] FIG. 4 is an illustration showing the preferred size of an example element;

[0024] FIG. 5 is an illustration showing an example of the element in FIG. 4 in a poorly arranged, resized window display;

[0025] FIG. 6 is an illustration showing an example of a visually pleasing resized window display created by the method of the present invention given preferred width;

[0026] FIG. 7 is a flow diagram representing the method of querying the display elements and computations for preferred height given width or width given height according to the present invention;

[0027] FIG. 8 is a flow diagram representing the method of determining preferred height given width for a text element according to the present invention;

[0028] FIG. 9 is a flow diagram representing the method of determining preferred width given height for a text element according to the present invention;

[0029] FIG. 10 is a flow diagram representing the method of determining preferred height given width for a container element according to the present invention; and

[0030] FIG. 11 is a flow diagram representing the method of determining preferred width given height for a container element according to the present invention.

[0031] Referring now to the drawings, and more particularly to FIG. 1, there is shown a diagram of the size queries typically answered by elements in the state of the art. An element will typically answer for its minimum dimensions represented in box 1 as h₁by w₁, its preferred dimensions represented by box 2 as h₂by w₂, and its maximum dimensions represented by box 3 as H by W. The element reports these dimensions in the form of height h and width w, giving a range of vertical sizing dimension h₁to H, and a range of horizontal sizing dimension w₁to W.

[0032] FIGS. 2 and 3 illustrate that for many elements the preferred width and height are not independent. FIG. 2 shows the preferred size of a wide or short element 4. Note that the display element 4 constitutes the box surrounding the text and not just the textual characters themselves. In other words, when the layout manager makes room for the display element on a given display, it must accommodate the size of the box 4. This element prefers to have a width w₄for a given height h₄, or alternatively, a height h₄for a given width w₄. FIG. 3 shows the preferred size of a narrower or taller element 5. This element now prefers a width w₅for a given new height h₅, or alternatively, a height h₅for a given width w₅.

[0033] Elements which hold flowed text are not the only types of elements for which preferred width and height are related. Elements which contain a large number of child elements, such as a frame around a number of buttons, and elements that contain images which may be scaled without distortion also have this property.

[0034] FIGS. 4 and 5 demonstrate the error which layout managers must introduce into their layouts given the size queries available in the state of the art, and FIG. 6 illustrates the correct layout enabled by this invention. FIG. 4 shows an element 6 containing the stacked text, “AUTOLOAN EXCHANGE” and its preferred size answer given as width w₆and height h₆. In FIG. 5, the layout manager has given the element 7 width w₇available on the display, in excess of its preferred width. However, the layout manager has given the element 7 its preferred height h₇. The element 7 now uses the extra width to write its contents on one line, leaving unused space above and below. In FIG. 6, the element 8 provided a better height h₈, given the available width w₈. In this example, the width of the elements 7 and 8 remains the same (i.e., w₇equals w₈).

[0035] FIG. 7 shows the general method used to query the element for preferred width given height (or preferred height given width). The layout manager queries the element in function block 1001 by sending the given width (height). The actual display element is an instantiation of the element class, with this query as a function, or method. The actual computational method used depends on the actual display element type, or sub-class. The flow diagram is illustrated with nested decision blocks, but this decision is actually unnecessary due to the nature of the object oriented design.

[0036] If the element is a flowed text element as determined in decision block 1002, the preferred height (width) is calculated in function block 1003. This computation is shown in FIGS. 8 and 9.

[0037] Referring first to FIG. 8, the text element calculated height given width by making use of a formatter which calculates the amount of text which will fit on a line of a given width with the given font. The given width and font are input to the formatter in function block 81. The formatter creates a row in function block 82 and then fills the row with text to fit the given width in function block 83. Each row of text has width and height properties. A test is made to determine if there is more text in decision block 84. The formatter yields rows of text in function blocks 82 and 83 until it has exhausted all of the text as determined in decision block 84. The text element requests each row from the formatter in function block 85. The height of the last requested row is added to the Sum in function block 86. The space to be added between rows (i.e., “leading”) is added to the Sum in function block 87 after it has been determined that there will be a next row, in decision block 88. If there are additional rows, as determined in decision block 88, the process loops back, adding the leading in function block 87 and then to function block 85 to request the next row. Once all of the rows have been summed, as determined in decision block 88, the resulting sum is reported as the requested height given width in function block 89. Note that the art of typesetting commonly refers to the space between rows as “leading”.

[0038] The text element uses the height given width calculation just described to determine width given height as shown in FIG. 9. A binary search is executed through the range of widths from the element minimum width to the element maximum width in function block 91. At each trial of the binary search it executes the height given width algorithm, as shown in FIG. 8, and described above. If the resultant height is greater than the given height, as determined in decision block 92, it increases the lower bound of the binary search in function block 93 and then continues with the binary search in function block 91. When the resultant height is within some desired number of pixels of the given height, as determined in decision block 94, but not more than the given height, the binary search is aborted and the current trial width is returned in function block 95. If the resultant height is less than or equal to the given height, it decreases the upper bound of the binary search in function block 96 and the next trial of binary search is executed in function block 91. If the binary search terminates, it returns the terminal width of the search. One should note that the number of pixels at which the search may be aborted, as determined in decision block 94, is an option which may be set by the caller, or layout manger. In the present invention, this parameter is set to approximately half the height of a row, not counting the “leading”.

[0039] Referring again to FIG. 7, if the element is of image type as determined in decision block 1004, it typically has a stored ratio of width to height and/or ratio of height to width that is used to calculate the preferred height given width (width given height) in function block 1005.

[0040] Another type of element implemented in the present invention is a “container” element. A container element is simply an element which includes other elements. A container element usually makes use of a layout manager to arrange the contained elements and determine its size requests. The layout manager as described in the concurrently filed, copending application Ser. No. 09/290,165 implements an enhanced method for arranging container elements. Referring again to FIG. 7, if the element is of the container type, as determined by decision block 1006, the preferred height given width (width given height) is calculated in function block 1007 which is shown in detail in FIGS. 10 and 11.

[0041] Referring first to FIG. 10, the container element calculates height given width by making use of a formatter which calculates the number of elements which will fit on a line of a given width. The formatter is initialized with the given width in function block 101. The formatter yields rows of elements until it has exhausted all of the elements. A new row is created in function block 102 and then filled with elements in function block 103. If more elements remain, as determined in decision block 104, the process returns to function block 102 and continues until no more elements remain. Each row of elements has width and height properties, and a property which gives the width needed to add the next element to the row. We refer to this last property as the “additional width” property. The additional width property of the last row is undefined. The calculations which follow disregard it. The container element requests each row from the formatter in function block 106. The height of the last requested row is added to the Sum in function block 107. If there are additional rows, as determined in decision block 108, the process loops back to function block 106 to request the next row. Once all of the rows have been summed, as determined in decision block 108, this resulting sum is reported as the requested height given width in function block 109.

[0042] The container element uses the height given width calculation, as shown in FIG. 10, and as described above, to determine width given height. Referring now to FIG. 11, the container element makes trials beginning with the minimum width of the element and ending at or before the maximum width of the element. At each trial it executes the height given width algorithm, as shown in FIG. 10 and described above, in function block 201. If the resultant height is greater than the given height, as determined in decision block 202, it returns the width tried in the previous trial, or if there was no previous trial, the current trial width is returned in function block 203. If the resultant height is less than or equal to the given height it increases the trial width by the minimum of the additional width properties of all the rows in function block 204. If the trials have attained the maximum width then the element returns the maximum width as the preferred width given height in function block 206.

[0043] Other types of elements will have their own methods for preferred height given width (width given height) as computed in function block 1008, as shown in FIG. 7. For instance, an element type might be implemented that requires table look-up, optionally interpolating between values in the table. One skilled in the art can easily create the appropriate computational methods for any element contemplated, and implement these computations in sub-class functions (methods) for any element permitting such sub-classes.

[0044] The method for determining values for the queries is implemented as a function, or method, in a layout manager class. One or more instances of this class are created and a specific layout manager object is referenced by each display element object. This reference, or registration, may be dynamically altered at run time by changing the reference to another supporting class which does the calculation. Moreover, the method for arranging elements performed by a layout manager may be row-ordered or column-ordered; rows could be stacked top to bottom or bottom to top; and columns could be stacked left to right or right to left.

[0045] Regardless of the element type, the preferred height given width (width given height) is returned to the querying function of the layout manager in function block 1009, as shown in FIG. 7.

[0046] In the state of the art, elements have methods which respond to requests for minimum, maximum and preferred size. These methods form an interface. All of the element s described here implement that interface, in addition to the interface for adaptive size requests newly disclosed here. They are therefore useful in the state of the art layout managers as well as in the improved art described in the concurrently filed, copending application Ser. No. 09/290,165

[0047] While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.