WO2001035217A2

WO2001035217A2 - Graphical user interface

Info

Publication number: WO2001035217A2
Application number: PCT/US2000/031351
Authority: WO
Inventors: Peter Warren; Steven Lowe
Original assignee: E-Brain Solutions, Llc
Priority date: 1999-11-12
Filing date: 2000-11-13
Publication date: 2001-05-17
Also published as: CA2360067A1; EP1259880A2; RU2001122574A; JP2003529818A; EP1247174A2; JP2003514300A; WO2001035216A2; NZ512939A; AU1611301A; WO2001035217A3; ZA200106526B; IL144319A0; RU2001122576A; WO2001035216A3; IL144314A0; AU1606201A; CA2359997A1

Abstract

The present invention is a graphical user interface that includes a single window in which active elements are painted. Each active element is not independent of the single window and includes a configuration panel and at least one tool operable with each active element to allow a user to alter the characteristics of the active element. Also included is a semi-automatic view generator operable on each active element provided the active element is a single record view of an object or a multi-record view of a group of like objects.

Description

GRAPHICAL USER INTERFACE

REFERENCE TO RELATED APPLICATION

This application claims the benefit of US Provisional Application No. 60/164,884, filed November 12, 1999.

BACKGROUND OF THE INVENTION

1. Field of the Invention The present invention relates to graphical user interfaces. Particularly, the present invention relates to a graphical user interface that consists entirely of a single window. More particularly, the present invention relates to a graphical user interface that consists entirely of a single window containing a desktop where all of the displays are painted onto the desktop. Even more particularly, the present invention relates to a graphical user interface where everything displayed on the screen is an "active element."

2. Description of the Prior Art

Increases in processing capability and decreases in the cost of personal computers have led to the proliferation of personal computers in all aspects of society. Personal computers are utilized in schools, homes and in business. With decreased costs of personal computers, it has become more feasible from a cost perspective to use computers for tasks and to carry out functions that were previously done without the use of computers.

With the proliferation of computers throughout numerous aspects of life has come a trend to graphic user interfaces that make using a computer more intuitive. Examples of such graphic user interfaces include IBM^® OS/2^®, Apple^® System 7^® and Microsoft^® Windows^®. These operating systems all rely on a "window like" workspace for applications, operating system information and program groupings.

In current generation systems, it is common for computer systems to incorporate so-called "object oriented" display systems that utilize multiple "windows" on a display in which combinations of text and graphics are disposed. Using a desk top metaphor, the windows may take the form of a variety of objects, such as file folders, loose leaf binders, or simple rectangles, and the windows may overlap one another with the "top" window constituting the current work file. A user operating within the context of a window-based graphic user interface (GUI) operates on objects commonly found in an office. This provides non-expert users with a familiar surrounding in which to interact with the computer.

In a typical window-based GUI system, visually distinct display objects are provided on the display screen, and are commonly referred to as "icons." Each of the icons represents a function or object on the desktop. In many systems, a cursor is also displayed that may be selectively moved in response to the movement of a mouse or other pointer control device. The cursor may be moved over display objects that the user may select on the screen. The user may delete information from a window, move data from one window to another, and generally operate on the windows as if an actual file or other physical object is being manipulated. A variety of pull-down menus also may be displayed, using a technique for selecting particular command options appearing along a menu bar, and subcommand items corresponding to the command options.

The reader is referred to the following references that describe various aspects, methods and apparatus associated with prior art graphic user interface design: US Patent No. 4,931,783, US Patent No. 5,072,4212, US Patent No. 5,148,154, US Patent No. 5,706,448, US Patent No. 5,524,196, US Patent No. 5,600,779, US Patent No. 5,488,685, US Patent No. 5,550,967, US Patent No. 5,966,126, US Patent No. 6,072,484, and references cited therein.

However, all prior graphical user interfaces provide multiple windows. The windows for the most part tend to be independent pieces of the desktop. These windows may contain various items such as icons, menus, command buttons, etc. associated with a particular window.

Generally, these various items are rectangular in shape and the user is not allowed to change the shape of a given item. In some limited instances, the user may be allowed to resize the shape within certain limits. In all instances, certain items such as menus and command buttons are particular to a given window and thus cannot be moved outside of the window with which it is associated. Furthermore, a user cannot change these items to a custom shape or alter and change any borders associated with a window, buttons, etc.

Therefore, what is needed is a graphic user interface where the GUI consists entirely of active elements. What is further needed is a GUI where all displays are painted into a single window, i.e. desktop. What is still further needed is a GUI where all the active elements are free to move out of their displays and around the desktop.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a graphical user interface where the interface consists of only a single window. It is another object of the present invention to provide a graphical user interface where everything displayed on the single window is an active element. It is a further object of the present invention to provide a graphic user interface where no pieces of the display are independent and where all displays are painted into the desktop. It is another object of the present invention to provide a graphical user interface where all of the active elements displayed in the single window are capable of being moved, resized and configured by a user. It is yet another object of the present invention to provide a graphical user interface where the simplest active elements can take various shapes and borders. It is also an object of the present invention to provide a graphical user interface where each shape can have multiple borders. It is still another object of the present invention to provide a graphical user interface where any active element can launch an activity and that it is not restricted to button-type or other special elements.

The present invention achieves these and other objectives by providing a method and apparatus for a graphical user interface that has a desktop display window consisting essentially of a single window, one or more active elements displayed on the single window where the active elements are drawn into the single window and where every active element is dependent on the single window, a configuration tool operable with each active element where the configuration tool permits a user to alter the characteristics of each active element, and a semi-automatic view generator capable of generating active elements to daisplay a single-record view of an object or a multi-record view of a group of like objects.

Although the following describes a preferred method and apparatus of the present invention based on Java software, a system design of the present invention may have various embodiments and embellishments based on other software languages without detracting from the unique characteristics of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGURE 1 illustrates an embodiment of the present invention showing various active elements of the graphical user interface.

FIGURE 2 illustrates an embodiment of the present invention showing the various shapes an active element of the graphical user interface may have.

FIGURE 3 illustrates an embodiment of the present invention showing an active element configuration panel.

FIGURE 4 illustrates an embodiment of the present invention showing a simple shape selection tool called a shape editor.

FIGURE 5 illustrates an embodiment of the present invention showing a simple border selection tool.

FIGURE 5A-5E illustrates an embodiment of the present invention showing each one of five different panels of the color selection tool called a color editor.

FIGURE 5F illustrates an embodiment of the present invention showing an enlargement of the transparency selector. FIGURE 6 illustrates an embodiment of the present invention showing a simple image selection tool.

FIGURE 7 illustrates an embodiment of a simple event editor tool of the present invention.

FIGURE 8A illustrates an embodiment of a simple text editor of the present invention.

FIGURE 8B illustrates an embodiment of the simple text editor of the present invention showing how the individual active elements of the present invention can be moved from each other and still function.

FIGURE 9 illustrates an embodiment of the drawing tool of the present invention.

FIGURE 9A illustrates an enlarged view of the tools panel of the drawing tool of the present invention that also shows various active elements separated from the tools grouping.

FIGURE 10 illustrates an embodiment of the present invention showing a multi-record view.

FIGURE 11 illustrates an embodiment of the present invention showing a single record view with embedded objects in various expanded views.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The preferred embodiment of the present invention is illustrated in Figs. 1-11.

The Framework

Referring now to Figure 1 , everything displayed on the screen 1 by the present invention is an "Active Element" 2. The simplest elements can take various shapes and borders. They can display a solid color or an image as a background. They can be moved, resized or configured by the user; and can store hints used by a parent element, if the element is a child element of a parent element, when they are laid out.

In the present invention, there are also some specializations of simple elements which are frequently used. The most significant ones are elements capable of displaying text such as label 3 ("12"), text field 4 ("ABC abc . . ."), button 5 ("New") and radio button 6 ("Bold") elements, and elements capable of managing the display of other elements such as parent 7 (the entire "Editor Tool" display), grid (not shown), button group 8 (the list of font names) and overlay elements (not shown). The displays of the present invention consist entirely of a single "window," i.e. the desktop. No pieces of the display are independent of that desktop. The desktop is a Java JPanel, not an active element. Its functions are to display all the elements the present invention is currently using, and to handle element moving and resizing. Typically it is displayed in a full-screen Java JFrame as the sole child of the frame. All elements of the present invention are "Java children" of the desktop, that is, contained by and displayed by it. No Java layout manager is used on the desktop, leaving the present invention parent elements free to manage the sizes and positions of their children. This also allows the present invention's "windows" to overlap each other, slide partially off screen, etc., behaviors which would be prohibited were the desktop to manage their layout. Those skilled in the art, i.e. Java programmers, will recognize and understand the references made throughout this preferred embodiment to the Java objects.

Many of the displays present the appearance of sub windows, and can be moved about and resized like traditional windows. However, this is an illusion. All the displays are painted into the desktop of the present invention. All active elements of the present invention have at least a shape, which is initially transparent. The minimum size of a simple element is 4 pixels in each dimension plus the size of its borders all around, if any. If an exact size is specified in its size hints, this size overrides the minimum. To construct an element, its name, identifier, and list of properties and events must be provided. This information is typically provided by the programmer/developer as default views or by a database. Details about properties and events are discussed later.

The shape of an active element defines its active portion. Unlike prior art graphic user interfaces, the user can change the shape of any active element of the present invention. The present invention provides a variety of shapes from which the user may choose. These include a box shape, an oval shape, a cloud shape, a triangle shape, and a custom shape. Referring to Figure 2, there is illustrated a variety of the shapes an active element may have. A box shape 10 is a simple rectangle created using a Java Rectangle2D object. The oval shape 20 is an ellipse or circle created using a Java Ellipse2D object. The cloud shape 30 is a custom construct, which can be resized without changing its form. No two cloud shapes will be exactly alike. The cloud is created by starting with a Java Ellipse2D object, just like an oval shape, using a size 200 pixels wide x 100 pixels high. The Java Pathlterator describing this object consists of equations for four cubic splines, one for each quadrant. Each spline consists of three pairs of coefficients that define the control points for the spline. A random value D between 30-50 pixels is chosen. Another Java Ellipse2D object of size 2D pixels wide x D pixels high is centered at each of the twelve control points. This appears to guarantee "reasonable" looking clouds. The cloud shape is the composite of the thirteen ellipses so generated. It is then resized to fit within the desired size of the element. A triangle shape 40 is a custom construct with its point facing up, down, left or right. This shape is very useful as a button control, but is not limited to that application. In the preferred embodiment, it is constructed from a Java Polygon object using the following pre-computed coordinates:

Up x = { 0, 50, 100 } y = { 100, 0, 100 }

Down x = { 0, 50, 100 } y = { 0, 100, 0 }

Left x = { 100, 0, 100 } y = { 0, 50, 100 }

Right x = { 0, 100, 0 } y = { 0, 50, 100 }

The result is then resized to fit within the desired size of the active element.

A custom shape (see the up- and down-pointing scroll buttons in Figure 1) is a construct which starts out as a plain box. Each side of the box can be left plain or changed by the user to a slant, point, bevel, semicircle, or rounded plain shape. Two directions are associated with each side. For example, the right side can be slanted lower-left to upper-right or lower-right to upper-left. It can be pointed right ("out") or left ("in") and so on. In these formulae, the preferred embodiment uses the following values:

SIZE = 100 SIZE_2 = SIZE / 2 SIZE_4 = SIZE / 4 SIZE3_4 = SIZE - SIZE_4 SIZE5_4 = SIZE + SIZE_4 BEVEL = round (SIZE / (2 + sqrt (2))) Pre-computed coordinates are used for each style and direction on each edge:

Up Slant Out x = 0, SIZE, SIZE } y = { 0, -SIZE_4, 0 }

In x = 0, SIZE, SIZE } y = { 0, SIZE_4, 0 }

Point Out X = 0, SIZE_2, SIZE } y = { 0, -SIZE_4, 0 }

In X = 0, SIZE_2, SIZE } y = { 0, SIZE_4, 0 }

Bevel Out X = 0, BEVEL, SIZE - BEVEL, SIZE } y = 0, -BEVEL, -BEVEL, 0 } In Xx == { 0, BEVEL, SIZE - BEVEL, SIZE } y = 0, BEVEL, BEVEL, 0 } Circle Arc2D (0, -SIZE_2, SIZE, SIZE, 0, 360, CHORD) Round RoundRectangle2D (0, -SIZE_4, SIZE, SIZE_2, SIZE_4, SIZE_4)

Down Slant Out x = { 0, 0, SIZE } y = { SIZE5_4, SIZE, SIZE } In x = { 0, 0, SIZE } y = { SIZE3_4, SIZE, SIZE }

Point Out x = { 0, SIZE_2, SIZE } y = { SIZE, SIZE5_4, SIZE } In x = { 0, SIZE_2, SIZE } y = { SIZE, SIZE3_4, SIZE } Bevel Out x = { 0, BEVEL, SIZE - BEVEL, SIZE } y = { SIZE, SIZE + BEVEL, SIZE + BEVEL, SIZE } In x = { 0, BEVEL, SIZE - BEVEL, SIZE } y = { SIZE, SIZE - BEVEL, SIZE - BEVEL, SIZE } Circle Arc2D (0, SIZE_2, SIZE, SIZE, 0, 360, CHORD) Round RoundRectangle2D (0, SIZE3_4, SIZE, SIZE_2, SIZE_4, SIZE_4) Left Slant Out x = { 0, -SIZE_4, 0 } y = { 0, SIZE, SIZE }

In x = { { 0, SIZE_4, 0 } y = { 0, SIZE, SIZE }

Point Out x = { { 0, -SIZE_4, 0 } y = { 0, SIZE_2, SIZE }

In x = { { 0, SIZE_4, 0 } y = { 0, SIZE_2, SIZE }

Bevel Out X = { { 0, -BEVEL, -BEVEL, 0 } y = {{ 0, BEVEL, SIZE - BEVEL, SIZE }

In X = {{ 0, BEVEL, BEVEL, 0 } y = {{ 0, BEVEL, SIZE - BEVEL, SIZE }

Circle Arc2D (-SIZE_2, 0, SIZE, SIZE, 0, 360, CHORD) Round RoundRectangle2D (-SIZE_4, 0, SIZE_2, SIZE, SIZE_4, SIZE_4)

Right Slant Out x = { SIZE5_4, SIZE, SIZE } y = { 0, 0, SIZE } In x = { SIZE3_4, SIZE, SIZE } y = { 0, 0, SIZE }

Point Out x = { SIZE, SIZE5_4, SIZE } y = { 0, SIZE_2, SIZE }

In x = { SIZE, SIZE3_4, SIZE } y = { 0, SIZE_2, SIZE }

Bevel Out x = { SIZE, SIZE + BEVEL, SIZE + BEVEL, SIZE } y = { 0, BEVEL, SIZE - BEVEL, SIZE }

In x = { SIZE, SIZE - BEVEL, SIZE - BEVEL, SIZE } y = { 0, BEVEL, SIZE - BEVEL, SIZE }

Circle Arc2D (SIZE_2, 0, SIZE, SIZE, 0, 360, CHORD) Round RoundRectangle2D (SIZE3_4, 0, SIZE_2, SIZE, SIZE_4, SIZE_4)

A Java Area object is formed as above. Where x and y values are given, a Java Polygon is used to form the area. For out-pointing sides, the area is added to a base rectangle SIZE x SIZE. For in- pointing sides, the area is subtracted from a base rectangle SIZE x SIZE. The finished product is resized to fit within the desired shape of the element.

The number of possible combinations is quite large. In the preferred embodiment, the most attractive ones modify only one side or two opposing sides. For example, a button with one side pointed or rounded can be used to indicate direction such as the up and down buttons on a scroll bar. A text field with a point "out" on the right end and a point "in" on the left end looks much like an arrow. Shapes frequently require resizing modifications. This happens when the element itself is resized and when borders are added to or removed from the element. The original shape and its size are stored for reference in the shape object. The new shape is obtained by scaling the original shape by a transform based on the new size divided by the original size, bigger or smaller as appropriate. The scaling can be different in the horizontal and vertical directions. If the resizing results from adding or removing a border, the shape is also translated to lie within the new borders. Text layout methods require horizontal rectangles of a given height that lie within a shape. In the preferred method, the present invention loops across the width of the shape's bounding box looking at rectangles of the given height and 1 pixel wide. If such a rectangle lies fully within the shape, and the previous one did not, the method starts tracking a new output rectangle. If the previous one lies within the shape, the method of the present invention moves the right edge of the output rectangle over another pixel. If the current rectangle does not lie within the shape and the previous one did, the method ends the output rectangle and stores it. When the right edge of the shape is reached and if an output rectangle is in progress, the method of the present invention stores it. The list of rectangles for the shape is returned.

Every active element has an active element configuration that may be changed by a user through the active element configuration panel. The preferred embodiment of the active element configuration panel is shown in Figure 3. it will be understood by those skilled in the art that the active element configuration panel 60 is itself a parent active element 61 having children active elements 70, 90, 110, 130, and 150, respectively, programmed using the methods of the present invention. The configuration panel 60 for the active element contains various options that allows a user to configure a particular active element. The user may change or not any one of the following by selecting shapes 70, colors 90, borders 110, events 130, or images 150.

As shown in Figure 4, a simple shape selection tool 71 (also configured according to the teachings of the present invention) called a shape editor is provided as part of the active element configuration panel 60. For the selected active element, the user can select a box (not shown), oval 73, cloud 74, triangle 75, or custom shape 76. If triangle 75 is selected, the user can choose to point it left 77, right 78, up 79 or down 80. If custom 76 is selected, for each edge the user can choose plain 81, slant 82, point 83, bevel 84, circle (not shown) or round styles (not shown), and whether the edge is pointed in 87 or out 88. To construct a shape editor, the list of available styles such as box, oval, etc. must be provided. For triangles, the list of directions such as up, down, etc. must be provided. For custom shapes, the list of edge styles such as point, slant, etc. and directions such as in and out must be provided. These lists may be provided by the programmer through default views or by the database with which the graphic user interface will interact. For the remainder of this detailed description of the preferred embodiment, any reference made where information is "to be provided," unless otherwise described, means that the information is provided by the programmer/developer or by the database as mentioned above. The active portion of each element of the present invention may have zero or more borders of various styles. If there are borders, they fit snugly within the box defined by the size of the active element. The active shape fits snugly within the borders. The user can change the style, color or number of borders of any element. Furthermore, borders can surround any shape, not just rectangles.

Border color can have a significant effect on the appearance of the border. Leaving the color "null" allows the software to compute appropriate border colors based on the background color of the active shape. Such borders are often the most attractive choice. In some situations, it is desirable to specify a color explicitly. In that case, border colors are computed from the specified color.

A plain border is a simple region of constant pixel width with a single color. It can be used as the innermost border around a text field, to provide some margin around the text, or between borders of other styles to "widen" them. The plain border has a width and a color. In the preferred embodiment, default values for the width and the color are provided as default one pixel for a width and null for a color. The plain border pre-computes and stores the area it needs to fill. The area is computed by taking the original shape and centering within it a second, similar shape, smaller all around by the width of the plain border. The smaller shape is subtracted from the larger. The annulus becomes the area of the plain border. The smaller shape is returned, and will become the active shape of the element. This technique works for all the shapes used for active elements and does not need to know what type of shape is receiving the border.

An etched border can be either raised or lowered. Lowered etched borders are often used as the outline for pushbuttons. Raised etched borders commonly delimit groups of related items in displays. The etched border has a color (default null). That color (or if null, the active shape background color) is used as the basis to compute a lighter and darker variant using the Java Color object's brighter() and darker() methods. All etched borders are 2 pixels wide. The etched border pre-computes and stores two areas it needs to outline. The upper-left area is computed by taking the original shape and reducing its width and height by 1 pixel. The upper-left corner remains fixed. The lower-right area is the same size, but its upper-left corner is offset by one pixel in both dimensions. The active shape is 4 pixels smaller in both dimensions than the original shape, and its upper-left corner is offset by 2 pixels in both dimensions. This technique works for all the shapes used for active elements and does not need to know what type of shape is receiving the border. Note that the etched border is not a perfect fit around the shape, but it is close enough for display purposes.

The only difference between etched raised and lowered borders is in how they are painted. A lowered border has areas outlined with colors as follows: lower-right area highlight color upper-left area shadow color A raised border has the colors reversed, as follows: lower-right area shadow color upper-left area highlight color

A beveled border can be either raised or lowered. Lowered beveled borders are often used as the outline for text fields. Raised beveled borders can delimit groups of related items in displays, or outline buttons for a 3-D effect. The beveled border has a color (default null). That color (or, if null, the active shape background color) is used as the basis to compute two lighter and two darker variants using the Java Color object's brighter() and darker() methods. All beveled borders are 2 pixels wide. The beveled border stores four areas it needs to fill. The areas involved are actually the same as those for the etched border, but each is subsequently split in half at its lower-left and upper-right corners. First an upper-left area is computed by taking the original shape and reducing its width and height by 1 pixel. The upper-left corner remains fixed. A similar area 1 pixel smaller all around is subtracted, leaving an annulus 1 pixel wide. The lower-right area is computed in a similar way as the upper-right area, but with the lower-right corner remaining fixed. Once these annular shapes have been obtained, they are split at the lower-left and upper-right corners, creating four areas to fill. The active shape is 4 pixels smaller in both dimensions than the original shape, and its upper-left corner is offset by 2 pixels in both dimensions. This technique works for all the shapes used for active elements, and does not need to know what type of shape is receiving the border. Note that the beveled border is not a perfect fit around the shape, but it is close enough for display purposes.

The only difference between beveled raised and lowered borders is in how they are painted. A lowered border has the areas filled with colors as follows: outer upper area lighter shadow color outer lower area darker highlight color inner upper area darker shadow color inner lower area lighter highlight color A raised border has the colors reversed, as follows: outer upper area lighter highlight color outer lower area darker shadow color inner upper area darker highlight color inner lower area lighter shadow color As shown in Figure 5, a simple border selection tool 111 is provided as part of the active element configuration panel. Active elements initially have no border. The tool displays border "#1" with style "None." The user can choose from etched, beveled and plain border styles. For etched and beveled styles, the user can choose raised or lowered. For the plain style, the user can choose a width. If border #1 112 is added to the element, border #2 113 will be displayed with style "None." As each new border is added, a slot or space will be provided for yet another border. There is no limit to how many borders can be applied to an active element.

Many attractive borders depend on a series of simple borders for their effect. Some common ones are etched raised followed by etched lowered (sometimes with a plain border between them to expand the frame), or beveled raised followed by beveled lowered. Many more complicated combinations are possible. To construct a border editor, the list of available styles such as plain, etched raised, etc. must be provided.

A color may be used in the active shape. Such colors may be opaque or partially transparent. The user can change the color used inside the active shape of any element. Colors in the preferred embodiment use the Java Color object, taking advantage of 24 bits of color information plus 8 bits of transparency. Note that the effect of active elements having a "shape" is achieved by painting the border and/or the active shape background. The color(s) used in the active shape can be opaque or partly transparent (a fully transparent color is stored as "null" and has no hue). Borders with no color of their own specified derive their colors from the active shape background color. Most borders use this method, since this generates an attractive, coordinated appearance.

As shown in Figures 5A, 5B, 5C, 5D, 5E and 5F, a color selection/editor tool is provided as part of the active element configuration panel. This tool is used throughout the present invention whenever a color is needed such as for the element background colors, for text foreground and background colors, for border colors, for colors in the drawing tool, etc. It consists of five different panels overlaid on each other. Turning to Figure 5A, in addition to the five different panels there is a scroller 92 to select the panel of interest and a slider 150 to set the transparency. The color editor is capable of displaying and selecting any of about 16 million colors (256 reds x 256 greens x 256 blues) at any of 255 transparencies for a total of about 4 billion combinations.

In Figure 5A, the color book tool consists of a panel 100 displaying a variety of colors, four radio buttons (red 101, green 102, blue 103 and gray 104) and a page slider 105. Initially, the "red" button is selected. A red color book has a constant red value everywhere on the panel. All possible green and blue combinations appear on the panel. Blue ranges from full off (0) at the top to full on (255) at the bottom. Green ranges from full off (0) at the left to full on (255) at the right. Changing the page of the color book with the page slider changes the fixed red value for the panel. Blue and green always cover the full spectrum. The user chooses a color from the panel by clicking on it.

The color book is a display technique for reducing a three-dimensional problem to two dimensions. Each page of the book is actually a slice taken from a color cube. The color cube has red full-on on one face and full-off on the opposite face. Green is full-on on another face and full-off on the one opposite. Blue is full-on on another face and full-off on the remaining one. The color book pages described above are slices taken from the cube parallel to the face where red is full on. Likewise, the green color book takes slices parallel to the green full on face. The blue color book takes slices parallel to the blue full on face.

The gray color book is just a single page long, and is provided as a convenience. All the gray values are available in the other books, but they are hard to pinpoint exactly. In the color cube, gray values lie along the line between the corner where all of red, green and blue are full on and the diagonally opposite corner where they are all full off. To construct a color book element, the current book (red, green, blue or gray) must be provided.

The color palette tool 110 is shown in Figure 5B. It consists of a few dozen colors 112 pre- selected for the user. The user chooses a color from the palette by clicking on it. To construct a color palette editor, the list of colors to display must be provided.

The red/green/blue tool 120 is shown in Figure 5C. It consists of a red slider 121, a green slider 122 and a blue slider 123. The red, green and blue sliders allow the user to adjust the color components individually. Red, green and blue values range from full off (0) to full on (255); each slider adjusts one of the components within this range. The user chooses a color by clicking on the slider and dragging it to a new position.

The hue, saturation and brightness tool 130 is shown in Figure 5D. It consists of a hue slider 131, a saturation slider 132 and a brightness slider 133. The hue, saturation and brightness sliders allow the user to adjust the color components individually. Hue, saturation and brightness values range from full off (0) to full on (1 ). Each slider adjusts one of the components within this range. The user chooses a color by clicking on the slider and dragging it to a new position. Note that brightness must be at least partially on (not full left) for hue or saturation to respond. Note that saturation must be at least partially on (not full left) for hue to respond. The values generated are converted to and from red, green and blue values using the Java Color object's RGBtoHSB() and HSBtoRGB() methods.

The red, green and blue text field tool 140 is shown in Fig. 5E. It consists of a red text field 141, a green text field 142 and a blue text field 143. The red, green and blue text fields allow the user to adjust the color components individually. Integer values between 0 and 255 can be entered. The user can also choose decimal values between 0 and 1. If any value exceeds 1 , the tool treats all three values as integers between 0 and 255, truncating any fractions. To avoid unnecessary and confusing color changes while the user is still typing, the color does not change until "Apply" is selected.

The transparency slider 150, which appears on all of the panels but which is more clearly shown in Figure 5F, allows the user to modify a color selected by any of the five methods described above to make it partially transparent. Transparency ranges from full off (0) to full on (255). The user chooses a transparency by clicking and dragging the slider 152 to a new position. A fully- transparent color has no hue and is stored as a "null" value. Moving the transparency slider 152 to full off leaves all color components set to full off (0). When the slider 152 is moved back again, the color will be black (red, green and blue full off) no matter what color was there before.

An image may be displayed in the active shape. The user can change the image displayed inside the active shape of any element. An image smaller than the active shape will be tiled to fill the active shape. An image larger than the active shape will be cropped to fit from the upper-left corner.

When an image is used as the background of the active shape, any color assigned to that region is no longer visible. However, any borders on the element without their own color specified still derive their colors from the active shape background color. When an image is used, it is appropriate to choose a complementary background color for the active shape to ensure smoothly coordinated borders. The images themselves have no effect on border color.

A simple image selection tool 160 is shown in Fig. 6. The image selection tool 160 is provided as part of the active element configuration panel. It displays a list 161 showing a small sample of all the images available to the tool, plus "None". An image is selected by clicking on it. When "None" is selected, the element will use its background color instead. To construct an image editor, the list of available images must be provided. Images in the JPEG and GIF formats are currently supported.

Another important aspect of the present invention is the use of size hints. Size hints are used by parent elements to help with the layout of displays. The "end of row or column" hint, if true, signals the layout routine to end the current row (in horizontal layouts) or column (in vertical layouts) after this element, even if more space is available. The "exact width or height in pixels" hint, if the width or height in pixels is provided, signals the desire of this element to be a specific size. For example it might be used with an image having a specific size preference. The "full width or height" hint, if true, signals the layout routine to make this element occupy the entire row (full width) or column (full height). The "maximum number of rows or columns" hint, if the maximum number of rows or columns is provided, tells the layout routine that more or less space is needed than might otherwise be expected. If a button group will have a scroller, maximum rows might limit the items displayed. If a scrolled label has the potential to display several digits, maximum columns might ensure enough space is available to view them all. The "uses all remaining width or height" hint, if true, signals the layout routine to give this element all the remaining width in a row (for horizontal layouts) or all the remaining height in a column (for vertical layouts). It does not mean the row or column ends with this element. It just requests that this element receive any excess pixels. The "vertical layout" hint, if true, tells the layout routines to use a vertical algorithm. Otherwise, a horizontal algorithm is selected. This hint is only meaningful when applied to parent elements. Other elements are atomic.

The active portion of the element can respond to various events initiated by a pointing device such as a mouse. The element may be moved or resized and its configuration controls may be launched. The mouse events used to initiate these tasks can be changed by the user. All elements currently use the same set of events for moving, resizing and configuration. Active elements store their events in a hash table as key/value pairs for easy retrieval. This also allows more complex elements, which inherit the basic active element behaviors, to store their own events without necessarily adding more data items.

Events are only triggered on the "active" portion of the element, that is, inside its shape. If an element is oval, clicking outside the oval does not fire the event. This is achieved by testing mouse events to be sure they occur inside the shape before processing them.

Any element can be moved relative to its parent, even outside the parent's apparent boundaries. The default control to move an element is holding the control key (Ctrl) and dragging the element with the left mouse button depressed.

Any element can be resized, even if the new size extends outside the parent's apparent boundaries. The default control to resize an element is holding the shift key (Shift) and dragging the element with the left mouse button depressed. Any element can be configured by the user. The default control to launch the active element configuration panel is clicking the right mouse button.

Any element can launch an activity. This behavior is not restricted to "buttons" or other special elements. Behaviors that can be started by an element are all lumped under the term "activation." Two sorts of activation are possible. Simple activation is a single event. The default control to activate a simple behavior is clicking the left mouse button. Complex activation is a series of events. An example is making a freestyle drawing in the drawing tool. The default controls for the series of events are:

1) Pressing the left mouse button to start the activation

2) Dragging the mouse with the left button down to continue the activation 3) Releasing the left mouse button to complete the activation

A simple event editor tool 170 is shown in Fig. 7. The event editor tool 170 is provided as part of the active element configuration panel. It displays a list 171 showing the events available for this element. Alternate mouse events or modifiers can be selected. To construct an event editor, the lists of editable events, mouse events and modifiers must be provided. Each active element has a list of associated properties. In the preferred embodiment, these properties are the shape property, the border property, the color property, the image property, the size hints property, and the event property. Active elements store their properties in a hash table as key/value pairs for easy retrieval. This also allows more complex elements, which inherit the basic active element behaviors, to store their own properties without necessarily adding more data items. Each property wraps up one or more bits of information.

The shape property stores one shape as described previously. An element has exactly one shape property. To construct an element, its shape type must be provided (box, oval, etc.). If the shape is a triangle, its direction must be provided (up, down, etc.). If the shape is custom, the style (slant, point, etc.) and direction (in, out) for each edge must be provided.

The border property stores a list of simple borders as described above. An element has at most one border property. If no borders are set, the border property is removed. The list of borders is stored outermost first. To construct an element with borders, its list of border types must be provided (plain, etched raised, etc.) with a color (or null) for each. For any plain borders, a width in pixels must be provided. However, an element need not have any borders. In fact, the list can be empty.

The color property stores a single Java Color object, also described above. An element has at most one color property for the active shape background. If the color is null (fully transparent), the property is removed. To construct an element with background colors, its background color must be provided as red, green, blue and transparency values (0-255). An element need not have background colors. It can be null.

The image property stores a single Java TexturePaint object plus a name describing the image. Images are compared for equality by comparing their names. An element has at most one image property for the active shape background. If it displays no image, the property is removed.

To construct an element with a background image, its background image must be provided as a file

(or a byte array) in JPEG or GIF format. An element need not have background images. Either or both can be null. The image property also provides the method for converting an image obtained from a graphics file to a Java TexturePaint object. The image file is loaded by a Java Imagelcon object.

GIF and JPEG image files are currently supported. The Imagelcon is painted into a Java

Bufferedlmage object, which is created to exactly fit the width and height of the image. Finally, the

TexturePaint object is created from the Bufferedlmage. The TexturePaint object has the ability to automatically tile itself to fit any area it is asked to fill. It is ideally suited for painting an image into the background of an element.

The size hints property stores one or more of the size hints. An element has at most one size hints property, which can contain any of the hints described above. If all the hints are false or zero, the property is removed. To construct an element with size hints, all of the values (true boolean or positive integer values) described under size hints above that are desired must be provided. An element need not have size hints. All of them can be false or zero, as appropriate.

The event property stores a single event. An element has a hash table of events, including at least move (move start, move and move end), grow (grow start, grow and grow end) and configure. Many elements also have simple (activate) or complex (activate start, activate and activate end) activation events. Any elements which can contain text also define events to get the focus and perform selection (select start, select and select end). The event property must store everything needed by the logic, i.e. software, it invokes. To construct an element with events, at least the following values must be provided for each event: its name, key, event identifier and action. It may also have event modifiers and an associated object. In the preferred embodiment, every element in the present invention has events. The move, grow and configure events are supplied automatically, but this is not required by the code.

The event property stores a name, which may be displayed to the user in the event editor if the user elects to change the event controls. The event property has a key, which the present invention uses to find the event in the element's hash table. The event property has an event identifier, stating which of seven mouse actions has occurred. Event properties can be used to sense when the mouse is clicked, pressed or released and when the mouse is dragged (movement with a button depressed). The event property has an event identifier, stating any control key(s) that must accompany the event. Control keys include shift, control and alt. Some systems also provide meta and/or altgraph.

The event property stores which active element owns the event, since that information is often needed by the logic the event launches. For example, when a button is clicked, its color is briefly changed as feedback to the user. The code needs the button's identity so that this can occur. The event property stores the name of an action (the logic) to perform if the event occurs. The input to such a logic is always the event property. The logic must obtain any other information it needs from items stored in the event property or directly available from the database (system- wide values).

The event property also stores an associated object. Not all events use this item. For example, when a button is clicked to close a window, the logic must have access to both the button itself (to change its color, as above) and to the identity of the window to be closed. The window identity is stored as the associated object. The event property stores the Java MouseEvent that triggered the event. In some cases, such as moving an element, freestyle drawing or marking a text selection, the exact coordinates at which the mouse was last placed are used by the code in responding to the event. These can be obtained from the MouseEvent.

Active elements which can display text are separated from simple active elements. These are called label active elements. They possess all the properties of simple active elements, plus a few new ones. The reason for the separation is that text processing is expensive, and it makes sense to streamline the process as much as possible. There is no other reason than speed for separating elements capable of displaying text from other elements. The text is managed by a property, and the property is stored in the same hash table as all the other properties discussed above. The distinction between simple and text-capable elements is used only to better explain the present invention and can be eliminated, if desired. The minimum size of a label element must be calculated. The one-line size of the prompt text is obtained. This is the size of the entire text up to the first "hard" line break, if any. If multiple lines are specified in its size hints, a multi-line size is then estimated. The width of the element's borders is added all around. A "hard" upper limit, currently set at 250 pixels, is used to constrain this size. Any exact size specified in the element's size hints overrides this minimum. The label element can have a "prompt," which contains text to be displayed to the user. The text is not editable under normal conditions, but becomes editable if the user launches the element configuration panel. The text in the prompt can be in any style or combination of styles, and can be long or short. The label element can have a justification, which can be leading, trailing or centered. Label elements have some additional events to which they respond. The set of mouse events is expanded, and keystroke events are added.

Prompts are only editable when the element configuration panel is displayed.

Label elements require a Java listener to await keystrokes. Keystrokes are only processed if the label is currently editable. However, the listener remains engaged all the time. Events are captured when a key is "typed" or "released." Key "press" events are ignored. When a typing, or printable, key is typed, the computer generates one or more key pressed events, a key typed event, and a key released event. When a key combination, such as Shift-A (for capital 'a') is typed, the computer generates one or more key pressed events for each key, a key typed event and a key released event for each key. The actual character typed is trapped from the key typed event, using the Java KeyEvent object's getKeyChar() method. It is stored in a holding buffer for a moment.

When key released events are received, if the key released is waiting in the typing buffer, it is processed, along with any keys ahead of it in the buffer. During rapid typing, it is possible to get a confusing series of key released events. This technique ensures that keystrokes are not lost and that they come out in the order they went in. Otherwise, key released events are treated as part of a keystroke-driven selection process.

Text can be selected using keyboard keys, if desired. The arrow keys, home and end keys and page up and down keys are used to navigate around text. To move the text cursor, starting from the current cursor position:

Left arrow moves back 1 character Right arrow moves ahead 1 character

Up arrow moves back 1 line

Down arrow moves forward 1 line

Page up moves back 1 page

Page down moves forward 1 page Home moves to the beginning of the page

End moves to the end of the page

Control-home moves to the beginning of the text Control-end moves to the end of the text No keys move the cursor past the end of the document or prior to the beginning. To mark text using these motion keys, the user holds down the shift key and navigates using the motion keys. The selection is highlighted in a pale color (by default, a pale magenta). When the shift key is released, the selection is "completed." Any further operation of arrow keys deselects the current selection and just repositions the cursor.

Text can also be selected using a pointing device such as a mouse. For many users, this is the normal method. Label elements have complex activation events called select start, select and select end (driven by default by left mouse press, left mouse drag and left mouse release). Text is highlighted in a pale color. When the mouse is released, the selection is "completed".

Label elements use two new property types, plus several helper classes used to style text and store layout information. Label elements have at most one justification property, which stores whether the text will be justified to the leading edge, trailing edge or center. Center justification is the default. If this value is chosen, the property is removed. "Leading" and "trailing" are sensitive to the preferred direction of the text. In right-to-left languages, "leading" will justify to the right edge and "trailing" will justify to the left edge. To construct an element with justification, the edge to use (center, leading, trailing) must be provided, in the preferred embodiment, an element need not have a justification. Center is used by default.

A simple justification editor is provided as part of the active element configuration panel. It allows the user to select leading, trailing or centered justification for the label element. To construct a justification editor, the list of available justifications (center, leading, trailing) must be provided. Label elements have exactly one text property, which by default contains an empty text string used as the prompt. To construct an element with a prompt, the text string to display must be provided. Often, the text style for each character is also supplied. The details for text styles are discussed later. An element need not have a prompt. An empty string is used by default. A text property with no text styles provided, or with text styles for only some of its characters, is still valid. The system default text style is used for any characters lacking text style values.

The text, when selected, in label active elements and text active elements can be manipulated and various characteristics of the text determined by the present invention. A supplied style can be applied to each character in the current text selection. The character position of every "hard" line break in a text string can be identified by searching through the string for '\n' characters. The size of a box needed to layout the given text in N lines, where N is provided, can be computed. It uses the one-line layout size as a basis and iterates on successively larger box sizes until all the text fits. The layout actually has to be performed to do this. The size of a box needed to layout given text in one line can be computed. The layout stops at the first "hard" line break, if any are encountered. The layout actually has to be performed to do this. Style ranges can be computed by organizing sequential runs of the same text style into style range objects. Only styles that differ from the default style are stored. This is done as a convenient space-saving measure. Word breaks can also be computed using a Java Breaklterator object to obtain the positions of every word break in a text string.

The visible characters can be counted. This method counts all the characters in a list of layouts. This count of characters visible can be used to estimate how far to scroll on page up or up arrow commands. Styled text can be created. This method creates a Java AttributedString from the given text string, replacing all "hard" line breaks with a single space each. The locations of the line breaks are stored. The original text is not modified. The text styles appropriate to each character then are applied. There is a major speed efficiency available by applying one style to a group of sequential characters, rather than repeatedly applying it to each individual character. A style list can be created from a list of style ranges. This method converts a list of style ranges into a list of text styles, one per character. All character positions not covered by one of the style ranges are supplied with the default style. Characters can also be deleted. This method deletes one character from the text. It also removes the style for that character from the style list, advises the undo logger of the change in that text property, and, if a text scroller is in use, adjusts the size of its slider. Further, a selection can be deleted. The delete selection method deletes one or more characters from the text, using the current text selection. It also removes the style(s) for those character(s) from the style list, advises the undo logger of the change in that text property, and, if a text scroller is in use, adjusts the size of its slider. Finding a caret layout given a caret position can also be performed. This method finds which of a list of layouts a given character position

(measured from the beginning of the text) lies in. If a point is given then a caret can also be found. This method finds which of a list of layouts a given x, y point lies in.

Finding a caret position is also possible. This method finds which character position a given x, y point lies over. It uses FindCaretLayoutGivenPoint in the process to obtain the layout containing the point, and returns both the layout number and the character position. The software can also find a caret position given an x-coordinate. This method finds which character position a given x-coordinate lies over, given the layout in which the x-coordinate lies. The present invention also allows the software to find carets after layout. After text has been laid out, this method uses FindCaretLayoutGivenCaretPos to discover which layout the caret position (and, if there is a selection, the other end of the selection) lies in.

Text in the present invention can also be acted upon using various keys from the keyboard defining their operation. For the backspace key if there is a current selection, this method deletes it using DeleteSelection. The cursor is placed where the selection used to begin. Otherwise, if the cursor is not at the beginning of the text, this method backs the cursor up one character and deletes a character using DeleteCharacter. The control-end key scrolls the text so the end of the text is visible on screen. This is estimated in the present invention, otherwise the process would be iterative. The control-home key scrolls the text so the beginning of the text is visible on screen. The delete key deletes a current selection, if there is a current selection, using DeleteSelection. The cursor is placed where the selection used to begin. Otherwise, if the cursor is not at the end of the text, this method deletes a character using DeleteCharacter.

The down arrow key moves the cursor, if the cursor is not on the last line of the text, down to the next line at approximately the same horizontal position. If the next line of text is currently off screen, it is scrolled on screen first. If the element's shape is non-rectangular, the text is shifted down by the number of characters in an average line. The end key moves the cursor to the end of the text on screen. The home key moves the cursor to the beginning of the text on screen. The left arrow key moves the cursor to the previous character if the cursor is not at the beginning of the text. If the cursor is at the beginning of a line, it moves to the end of the preceding line. If the preceding line is off screen, it is scrolled on screen first. If the element's shape is non-rectangular, the text is shifted up by the number of characters in an average line.

The page down key scrolls the text down by a page if the end of the text is not visible on screen. The first character of the new page will be the character after the last character displayed on the previous screen. The page up key scrolls the text up by approximately a page if the beginning of the text is not visible on screen. The last character of the new page will be near the character before the first character displayed on the previous screen. This is estimated in the present invention, otherwise the process would be iterative. The right arrow key moves the cursor to the next character if the cursor is not at the end of the text. If the cursor is at the end of a line, it moves to the beginning of the next line. If the next line is off screen, it is scrolled on screen first. If the element's shape is non-rectangular, the text is shifted down by the number of characters in an average line.

The scroll down one line method handles scrolling down by a line in the general case, where the text may be laid out in an arbitrary shape. It uses the mean characters on screen per line (total characters / total lines) to decide how far to scroll. The scroll up one line method handles scrolling up by a line in the general case, where the text may be laid out in an arbitrary shape. It uses the mean characters on screen per line (total characters / total lines) to decide how far to scroll. The up arrow key moves the cursor up to the previous line at approximately the same horizontal position, if the cursor is not on the first line of the text. If the previous line of text is currently off screen, it is scrolled on screen first. If the element's shape is non-rectangular, the text is shifted up by the number of characters in an average line. The insert character method inserts one character from the text. It also inserts the style for that character into the style list, advises the undo logger of the change in that text property, and, if a text scroller is in use, adjusts the size of its slider. Layout text across a shape, referred to earlier, is a helper method that lays out one line of text across an arbitrary shape. Rectangular shapes do not need to invoke it. The following values are provided: the text property, the shape, a Java LineBreakMeasurer object holding the styled text, a Java Rectangle object specifying how tall the next bit of text is, a list of line break positions, which of those line segments is currently in progress, and the justification to apply.

Using the height provided, a list of rectangles across the shape is obtained from the shape's getHorizRects() method. For each rectangle, an attempt is made to layout some text in it. This is done by using the Java LineBreakMeasurer object's nextLayout() method with the width of the rectangle and the position of the next line break. Only layouts containing at least one full word are used.

If a layout is obtained, it is stored as a TextLayoutStore, which also keeps track of character positions and physical display coordinates. The tallest layout is tracked to know how far to advance when all the rectangles are completed. If a line break has been reached, the counter advances to the next text segment. When all rectangles are complete, the y-value is moved to below the tallest layout obtained. If no layouts are obtained, it moves down one pixel. The list of layouts and current line segment number are returned.

Layout text within a given shape method turns styled text into a list of layouts which fit within the given shape. The text property, shape and justification are provided. A Java

AttributedCharacterlterator is obtained containing the styled text. A Java LineBreakMeasurer is created from it. A rectangle describing the bounds of the shape is obtained. The text property is asked for a list of its line breaks. Text is laid out a line at a time, looping through the line breaks. It is important to note that it is normal for one "line" of text (commonly a single paragraph) to span many "lines" of layout. The next layout is obtained from the Java LineBreakMeasurer object's nextLayout() method using the width of the bounding rectangle and the position of the next line break. The layout must contain at least one word.

If the layout "hangs off' the bottom of the bounding rectangle by more than half its height, then the method is done. If the shape is itself rectangular, the layout can be stored as is, using a TextLayoutStore object to keep track of its starting position and coordinates. The character position is updated and then the method goes on to the next line. If the shape is non-rectangular, the existing layout is used to estimate the height required, the Java LineBreakMeasurer is backed up to its previous starting point, and the LayoutTextAcrossShape method is used to obtain layout(s) across the shape. All TextLayoutStore objects created and stored are returned. Multi-line selection is also possible with the graphic user interface of the present invention.

This method marks a multi-line selection, using repeated calls to MarkSingleLineSelection to do the work. It marks from the start position to the end of the layout in which the start lies, any full lines, and from the end position to the beginning of the layout in which the end lies.

A single-line selection can also be marked. This method builds a rectangle which surrounds all the characters in a single layout marked for selection. When the text is painted, the rectangle will be filled with the selection color. Text can also be painted. This method draws the text. First it loops through all the layouts stored, drawing them at the stored coordinates (the Java TextLayout object can be drawn directly). If the element is editable and there is a text selection, the selection is filled with the selection color. Finally, if the element is editable, its text cursor is painted (in bi-directional languages such as Arabic, there may be two cursors under some conditions). The present invention also allows for examining a current keystroke received. If the current keystroke received is a backspace, it is handled using HandleBackspaceKey. If not, and there is any text selection, the selection is deleted using DeleteSelection. Then the character is inserted using InsertCharacter. Because it is possible to get backlogged during rapid typing, this method processes everything in its typing buffer up to and including the current keystroke received. A key code processing method handles processing of the arrow keys, home and end keys and page up and down keys, by invoking the appropriate method above. When text is scrolled by a line or a page, a "start on word boundary" method moves the starting character position at the top of the page (if necessary) to ensure it lies at the beginning of a word.

A particular helper class called "text layout store" stores a single Java TextLayout object plus additional information needed to display it. The TextLayout object contains a single line of text. A multi-line document requires a list of TextLayout objects to display itself. The layout store keeps track of the coordinates at which the layout should be displayed, the width and height of the actual text, the character position within the whole text at which this layout starts. This class can also figure out the x-coordinates of each character in the text it has laid out. This information is only computed if needed. Handling up and down arrow keys and marking selections require this level of detail. The layout is used to obtain the cursor shape at each character position in turn. The x-coordinates of the positions are saved.

The text style helper class stores the information needed to create a single text style, in the form of a hash table of key/value pairs. The keys are Java TextAttribute constants. The values are of various types, as appropriate for each attribute. The text style object is in a form which can be used directly by the Java AttributedString object, which can apply the style to one or more sequential characters. To construct a text style, at least the font family (Arial, Courier, etc.) and size (in points) must be provided. As necessary, the font weight (bold or not), posture (italic or not), strike through (on or off), underline style (one of six, or off), superscript or subscript level, foreground and background colors may also be provided.

The font family is supplied as a string, such as "Arial" or "Courier." Since the list of font faces available varies from computer to computer, the present invention obtains the list of available fonts from the computer. The family attribute expects a Java String value. A text style must have a family attribute. Java expresses font size as a decimal value in points (a point is 1/72 inch). Most font faces support variable size. Some only support specific integer font sizes (for example, 8-, 10- , 12- and 16-point are common). The size attribute expects a positive Java Float value. A text style must have a size attribute. Java expresses font weight as a decimal value with a practical range of 0.25 to 2.75. Traditional "bold" is assigned the value 2.0. "Normal" is assigned the value 1.0. Values less than 1.0 would appear "lighter" than normal. The present invention treats boldness as a Boolean attribute (on for bold, off for normal). The text style object converts the value. The weight attribute expects a Java Float value between 0.25 and 2.75. If the value is 1.0, the attribute is removed.

Java expresses font posture as the arc tangent of the skew angle from +90 degrees (tilted right, value +infinity) to 0 degrees (normal) to -90 degrees (tilted left, value -infinity). Traditional "italic" is assigned the value 0.2. "Normal" is assigned the value 0.0. Values less than 0.0 would appear "tilted" to the left. The present invention treats italics as a Boolean attribute (on for italic, off for normal). The text style object converts the value. The posture attribute expects a Java Float value. If the value is 0.0, the attribute is removed.

Java expresses strike through as a Boolean attribute, true if on, false if off. The strike through attribute expects a Java Boolean value. If the value is false, the attribute is removed. Java expresses underline as an integer attribute. There are six styles of underline provided by Java: standard (at the Roman baseline), single (1 -pixel, below the descenders), double (2-pixel), gray, dashed and dotted. The underline attribute expects a Java Integer value (the TextAttribute class provides constants for the six values). If the value is not among the six constants, the attribute is removed.

Java expresses superscript and subscript as a single integer attribute, using positive values for superscripts, negative values for subscripts and zero for normal positioning.

Unfortunately, the Java mechanism does not currently either scale or offset the text to create a superscript or subscript. The text style class of the present invention provides a work around to create superscripts and subscripts. However, it is not completely satisfactory. For example, the text background color does not track with it properly. Future development will probably resolve this problem.

The scale factor to apply to the font size is 2/3 raised to the "level" power, where level is the magnitude of the superscript or subscript value (i.e. 1 , 2, 3, etc., values above 3 generally result in superscripts too small to read). The offset to use for translation is computed iteratively: factor = 1 offset = 0 size = font size/2 level = magnitude of superscript or subscript repeat level times factor = 2/3 x factor offset = offset x 3/2 + size x factor end repeat Finally, the font is transformed by scaling it by a factor in both dimensions and translating it by offset in height (use -offset for superscripts).

Java uses Java Color objects for the foreground and background color attributes. If the color is fully transparent (null), the attribute is removed. The style range helper class stores a text style and a starting and ending character position. The start position is the first character to which the style applies. The end position is one past the last character to which the style applies. Style ranges are used when a text property is stored, to compact the style information.

A simple text style editor 180, shown in Figure 8A, is provided as part of the active element configuration panel. It allows the user to change all the attributes of the font and to view a sample of the result. To construct a text style editor, lists of options such as font family, font size, font weight, font posture, underlining, strike through, superscript and subscript, and foreground and background colors, as described below must be provided.

The text style editor 180 provides a Font family selection list 182. A list of the available font families is provided. The user can select one by clicking on the desired font. To construct a font family list, names of all the available fonts must be provided. A scroller 183 for font size allows the user to adjust the font size up or down a point at a time using buttons. The user can toggle the font weight, i.e. bold, on or off by clicking on a "bold" radio button 184. For italics, the user can toggle the font posture, i.e. italics, on or off by clicking on an "italic" radio button 185. Underlining is also provided. The user can select one of six underlining styles or no underline by clicking on the desired style shown at 186. To construct an underlining list, names of the styles of underlining, plus "None," must be provided. For strike through, the user can toggle strike through on or off by clicking on a "strike through" radio button 187.

Superscripts and subscripts can also be designated by the text editor 180. The user can select normal, superscript or subscript positioning by clicking on the position desired at 188. Text editor 180 also provides the user with the option to modify the font foreground or background color. The buttons 189 and 190 for these colors launch the color editor described earlier.

Text elements extend label elements by adding the concept of an editable text field to the label element's prompt. Text elements thus have two text properties available in which to store text, in text elements, the "prompt" takes the role of providing feedback to the user about what is desired and the text field receives typing input from the user or displays a value for editing. The text field and prompt interact with each other. When any text is available in the text field, the text field is displayed. When the text field is empty, the prompt is displayed. Under normal conditions, the text field is editable by the user, the prompt is not. The minimum size of a text element must be calculated. The longer of the text field and the prompt text is used, as an approximation, to avoid doing this twice. The one-line size of the text is obtained. If multiple lines are specified in its size hints, a multi-line size is then estimated. The width of the element's borders is added all around. Any exact size specified in its size hints overrides this minimum.

The text element has a "text field," which contains text to be edited by the user. If the user launches the element configuration panel, the prompt becomes editable and is displayed instead of the text field. The text field will reappear when configuration is completed. The text in the text field can be in any style or combination of styles, and can be long or short.

To construct an element with a text field, at least the text string to display must be provided. Often, the text style for each character is also supplied. The details for text styles are covered below. An element need not have a text field. An empty string is used by default. A text property with no text styles provided, or with text styles for only some of its characters, is still valid.

The system default text style is used for any characters lacking text style values.

Button elements are specializations of label elements. They are typically used to launch various activities. Like label elements, they can display text but they are not required to. The minimum size of a button is based on the minimum size calculated by its label ancestor, which ensures any text can be displayed. It cannot be less than a fixed minimum, currently 16 pixels, in each dimension. This ensures the button is big enough to operate. The border width is added all around. Any exact size specified in its size hints overrides this minimum.

Simple buttons add the concept of an "armed" state to the behaviors of their label ancestor.

A button is armed when the user presses it and disarmed when the user releases it. This state is monitored by the button's paint method. The background is changed to a slightly darker color when the button is armed, and restored when it is disarmed. If the button's background is painted with an image, no visual feedback is currently provided. Simple buttons use the activate start and activate end events to invoke arm and disarm behavior and the associated repainting. With rare exceptions, simple buttons also have an activate event, specified by the programmer, to indicate what action to take when they are pressed. By default, button activation uses a left mouse click. Radio buttons extend simple buttons by adding an on/off selection state. In the present invention, these buttons serve several purposes. In groups, they provide traditional "radio button" functionality, i.e. exactly one button in the group can be on at any time. Such groups are used for offering a set of mutually exclusive choices. Standing alone, a radio button serves the purposes of a traditional "check box," displaying different borders when selected and unselected. Finally, in a group with a scroller, they provide "combo box" or "scrolled list" functionality.

Currently, radio buttons use an underlying Java JRadioButton object (not displayed) to store the selection state. This allows the use of the Java ButtonGroup object to manage exclusivity in groups of buttons. Parent elements have the responsibility of managing one or more child elements. Parent elements extend simple active elements. Their children can be any simple element, or any element that extends simple element behavior. So parents can have other parents as their children. This is the basis for the hierarchy of elements that builds up application screens.

Unlike the practice in traditional windowing frameworks, the parent-child relationship in the present invention does not imply containment. A child can be moved, by the user or the developer, outside the boundaries of its parent. Children move and grow with their parent, but do not need to be contained by it (some of this behavior is constrained by the layout algorithms). Children can also overlap each other. This behavior is also somewhat constrained by the layout algorithms. To construct a parent element, the list of its children must be provided. A parent does not need to have any children. This list can be empty. Parent elements keep a list of their children. Each child has a name, used by its immediate parent for identification purposes. The developer must ensure the names for all children of one parent are unique. No "global" uniqueness is required. The purpose of the names is to allow code to address a specific child in a maintainable, human-readable way. The list of children controls the order in which they get painted. This is only important if the children overlap, in which case the last ones will appear "on top." There is also a hash table of children, keyed to their names, to allow the code to rapidly locate children by name.

The layout of the children involves several steps. The first step is finding out how big the entire hierarchy of elements "wants" to be. In practice, this involves evaluating the minimum size required for each element and piecing the whole together. Good values can be obtained for most simple elements, including labels and text fields with a small amount of text. Problems arise with "large" text fields. There is no "right" answer for what size they need to be. It is possible to have a one-line high layout, very, very wide, or a one-word wide layout, very, very tall, or anything in between. When there is only one such field, size hints can handle the problem. They allow the developer to allocate "all remaining" space to a particular element. Once the required size is known, the actual layout is performed. Often, displays are laid out to their minimum size. For simple editors and control panels, this usually looks pretty good. If more space than the minimum is to be used, the excess can be distributed across all elements or concentrated in just one. Size hints decide which approach is taken. The general layout strategy, using horizontal layout as an example, is: 1. See how many elements fit on the next row, observing any size hints

2. Center the row in the space available, in both dimensions

3. Set the position and size for each element in the row

4. Move down to a point below the tallest element in the row

5. Repeat for the next row The strategy for a vertical layout is similar. Error checking of the size hints and conflict resolution in general may be incorporated as the developer sees fit for the intended application. Grid layouts are used for automatically generating "table" views in the present invention, and are useful in a number of custom layouts as well. Grid layouts organize their children into a two-dimensional "list of lists." Size hints determine whether the sublists are rows or columns (i.e. is the layout horizontal or vertical), and which element is at the end of each row or column. The rows or columns do not need to have the same number of elements, nor does the size of the grid need to be specified in advance.

The layout strategy is that all elements in the same column will be the same width. All elements in the same row will be the same height. This is true in either horizontal or vertical layouts. The only difference between them is whether sequential elements go in the same row (horizontal) or column (vertical). Arrays of column widths and row heights are calculated, using the desired minimum size of each element as a basis and finding the widest element in each column and the tallest element in each row. The columns will commonly each have a different width. The rows will sometimes each have a different height. Size hints can designate one column to absorb all excess width if desired, and one row to absorb all excess height. The actual layout is straightforward once the column widths and row heights have been calculated. The grid is intended to allow widths exceeding the available screen space by wrapping each row onto two or more lines, retaining all other grid behaviors described above.

Button groups extend grid elements to provide exclusivity. All children of a button group must be radio button elements. Exactly one child must be selected all the time. There is no state with all children deselected. To implement this sort of behavior, radio buttons in a plain grid layout are used. The developer must then manage both selection and deselection.

Overlays provide a way of displaying several alternatives in series. Exactly one of the alternatives is displayed at a time. Typically the children of an overlay element are each parent elements of some sort, but that is not a requirement. The overlay provides methods to set which child is currently in view. Controls which allow the user to select from the available alternatives must be provided externally. Overlay elements can provide "wizard" or "tabbed panel" behavior. The minimum size of an overlay will be the size of the largest of its children. To construct an overlay element, the current child to display must be provided.

Scrollers serve two purposes. One is to allow traversal of material too large to fit in the available space. The present invention has vertical scroll bars for grid elements and for label or text elements to fill that need. The second is to allow the user to choose from a range of numeric values without typing. The present invention uses both horizontal and vertical sliders and scrolled labels for that purpose.

Scrollers are customized parent elements whose children work together to create the appearance of a traditional scroll bar, slider, etc. Unlike traditional windowing environments, scrollers of the present invention can be freely changed by the user. The individual pieces 201-204 (shown in Fig. 8A), which are each active elements, can be moved, reshaped, painted, etc., as shown in Fig. 8B as 201'-204\ respectively. The scroller can be dragged away from the item it controls and still function. Some of these behaviors are affected by the layout algorithms.

The vertical grid scroller creates the appearance of a traditional scroll bar. It has up and down buttons, a slider, and a trough in which the slider appears to sit. To be useful, it must be associated with a grid element whose size hints indicate how many rows are to be displayed, and the grid must contain more than that many rows. On layout, the scroller can collapse its slider and trough if the available height is insufficient. Only the up and down buttons remain. For example, a list restricted to one item in height paired with a collapsed scroller works something like a standard combo box. Assuming these conditions are met, the scroller allows the user to slide the grid view up and down, bringing rows into the view from off screen. Clicking the up or down buttons scrolls the grid by one row, until the beginning or end of the grid is reached. Dragging the slider with the mouse button depressed scrolls the grid freely between its limits. The trough is not active at this time. Clicking in it has no effect. Shown in Figure 8A, the vertical text scroller 200 creates the appearance of a traditional scroll bar. It has up and down buttons 201 and 202, a slider 203, and a trough 204 in which the slider appears to sit. To be useful, it must be associated with a label or text element containing more text than will fit within its boundaries. On layout, the scroller can collapse its slider and trough if the available height is insufficient, only the up and down buttons remain. Assuming these conditions are met, the scroller allows the user to slide the text view up and down, bringing lines into the view from off screen. Clicking the up or down buttons scrolls the text by one line, until the beginning or end of the text is reached. Dragging the slider with the mouse button depressed scrolls the text freely between its limits. Like the horizontal text scroller, the trough is not active at this time. Clicking in it has no effect. Horizontal and vertical sliders allow the user to adjust numeric values between fixed limits without typing, and without knowing the actual values. The numeric limits are assigned to the ends of the slider. The user drags the slider between them using the mouse. Values range linearly between the limits. The slider is composed of a trough and a knob. Only the knob is active. To construct a slider, its minimum, maximum and current values must be provided. Scrolled labels behave like a list of values with up and down buttons. The value is changed each time a button is clicked. They are suitable for fixed ranges of integer values. To construct a scrolled label, its minimum, maximum and current values must be provided.

The Drawing Tool Turning now to Figure 9, the drawing tool 210 of the present invention is constructed using the methods previously described, i.e. creating active elements for each component of the drawing tool. The drawing tool 210 allows the user to assemble a collection of shapes. Individual shapes can be easily manipulated in various ways. The collection of shapes can also be moved and resized. A finished drawing can be named and saved. When the drawing is reloaded, the shapes can again be manipulated individually. The save format is very compact (equations for the shapes, plus color and border width information) and does not lose accuracy compared to the original drawing. To construct a drawing tool, no special information is required. To reconstruct a drawing, the list of shapes to display must be provided. Details for the shapes are discussed below.

Several styles of shape are available: box 212, oval 213, rounded box 214, and right triangle 215. The user can also draw straight lines and freestyle lines (scribbles). Shapes are stored in the drawing tool as Java Shape objects. They are stored in the database as coordinates from the Java Pathlterator associated with the shape. To reconstruct a shape, the following information must be provided: the type of shape (oval, triangle, etc.), its border width, its rotation angle, its center and border colors, its Java winding rule, and the list of Java segment types and coordinates which define the shape.

Each shape has a border around it, initially one pixel wide. The current width of the border is stored for each shape. Each "solid" shape has a center color and a border color. They may be the same if desired. Lines and scribbles only have the border color. The color editor tool used here was described earlier. Like other colors in the present invention, colors in the drawing tool can be opaque or partially transparent. To set the center color, use the color editor to select the color desired, then click on the box 215 labeled "center." The border color is set similarly by clicking on the box 216 labeled "border." The border and center colors are stored for each shape. A simple click or click-and-drag model is used for all the actions in the drawing tool, which makes it fairly easy to use. To set the colors of a shape in the drawing tool, the user selects the "set colors" button 217. When the user then clicks on a shape, its center and border colors are changed to the currently selected center and border colors. To get the colors used by a shape, the user selects the "get colors" button 218. When the user then clicks on a shape, its center and border colors become the currently selected center and border colors. A pop to front action button

219 allows the user to pop a selected shape in front of all other overlapping shapes. This is implemented in the code by moving the shape to the end of the shape list. A push to back button

220 allows the user to push the shape in back of all other overlapping shapes. This is implemented in the code by moving the shape to the beginning of the shape list.

A delete button 221 is coded so that when a user selects button 221 and then selects a shape, the shape is deleted from the drawing. A move button 222 is coded to allow the use to move a shape around the screen. Button 222 is coded to cause a shape to follow a pointing device cursor on which the user clicks and drags. When the user clicks and drags a shape, it follows the mouse cursor around the screen. Drawing tool shapes are confined to the drawing tool center area 221, but can be dragged off the edge of it and out of sight. The "pan" feature described below can be used to shift the shapes until the missing one reappears. Once it reappears, then it can be moved back where it belongs.

A resize button 223 is included to allow the user to resize a shape. When the user clicks and drags a shape, it is resized following the mouse cursor around the screen. If the shape has been rotated, the direction of resize may not be very intuitive. Resize is implemented along the axes of the shape itself, independent of rotation, so as not to skew the angles in box, rounded box or right triangle shapes.

A shape can be rotated using a rotate button 224. The code is written such that when the user clicks and drags a shape, it spins around its approximate center. The user can rotate it freely in either direction as much as desired. The rotation angle is stored with each shape.

The border width of each shape can also be changed with button 225. When the user clicks and drags a shape after selecting button 225, its border width can grow or shrink. The current border width is stored with each shape. Borders are drawn centered on the outline of the shape. In the drawing tool of the present invention, several actions affect all the shapes at once.

The pan all button 226, when activated, causes all the shapes to follow the pointing device cursor around the screen when the user clicks anywhere in the drawing area. The initial click does not have to be anywhere particular. The zoom button 227, when activated, causes all the shapes to grow or shrink together following the pointing device cursor around the screen when the user clicks anywhere in the drawing area. The initial click does not have to be anywhere particular. To keep the angles in box, rounded box and triangle shapes from skewing, the resize is identical in both directions.

When the user selects button 228 for a new drawing, the old drawing is erased. To load a drawing to the screen, the user must supply a drawing name to text field 240 and then selects button 229. When the drawing name is supplied, the drawing is loaded into the drawing area 211 of drawing tool 210 and is added to whatever appears on the screen. If the old drawing is to be removed first, select new drawing before loading. To save a drawing, the user must supply a drawing name to text field 240 and then selects button 230. When the user supplies a drawing name and saves it, the drawing will be stored.

Automatic View Generation

The present invention can generate a single-record view of an object, or a multi-record tabular view of a group of like objects semi-automatically.

Turning now to Figure 10, a multi-record view 250 is like a table. Each object occupies one row 252. Each field 254 within the object occupies one column. A header row 256 lists the field names. To construct a multi-record view, the list of records to display must be provided. For each record, the fields to display and their formatted values must be provided. Sorting takes place on the field contents themselves, not the formatted values which may actually be displayed.

The multi-record view allows a user to sort on any column. The header row 256 consists of active buttons 257 labeling each column. Clicking one of the buttons sorts the table according to the contents of that column. The sorts are "intelligent." Since the underlying data are true Java objects, numbers and dates sort just as correctly as text strings. Clicking the same button again reverses the sense of the sort, from increasing to decreasing or back again.

The multi-record view also provides the ability to display single-record view of any row. The left-most column contains a button 258 for each row. Clicking the button opens a single-record display of the object in that row.

Turning now to Figure 11 , a single-record view 270 is like a two-column table. The left column 272 contains the field names and the right column 274 contains the data. Simple fields containing text strings, numbers, dates, etc. are displayed as text fields for editing. The single- record views also contain buttons to display related objects. To construct a single-record view, the list of fields to display and their formatted values must be provided. If any of the fields are themselves objects within the present invention, a method exists to request the list of fields for that embedded object in turn. If the displayed object is itself a field within objects of other types, those object types must be provided to construct the single-record view. The single-record view displays push button connections to them, as shown in Fig. 11 as A, B and C. Any embedded object can be expanded. Fields that contain other objects are displayed as radio buttons 280 and 300. Pressing such a button 300 expands the embedded field as a single- record view 302 contained within and indented relative to the initial single-record view. If the expanded field itself contains other objects 304, those objects can also be expanded. Both indentation and slight color coding help to isolate such expanded fields. One button in the single-record view allows the user to display a multi-record view of all objects of the same type as the current object. Other buttons 306 may appear in the single-record view if the current object is a field within other objects. All "related" objects can be displayed, i.e. objects which contain this specific object in one of their fields. This recursive ability to drill down through the data is very powerful. In addition, the present invention uses certain "constants" that may be made available to the user to configure, depending on the developer's inclination and the application. The TIMER_DELAY "constant" is the delay time used by label elements for the layout and repaint timer. Its default value is 250 milliseconds. The timer keeps layout and repaint activities from bogging down a rapid typist. No matter how rapidly changes are supplied, layout only occurs every 250 milliseconds. The EMBEDDED NDENT "constant" is how far embedded objects are indented from their parent in single-record views. The default value is 20 pixels per level. So if a MoneyMovement object contains an Account object, the Account object will be indented by 20 pixels. If that Account itself contains a Currency object, the Currency object will be indented 40 pixels, and so forth.

The FACTO R_PER_PIXEL "constant" is the logarithmic scale factor used for the drawing tool "zoom all" capability. The default value is 0.01/pixel. As the user drags the pointer device in the "bigger" direction during zoom (east and/or south, the +x and +y directions), the sizes of the shapes double after the first 100 pixels. After the next 100 pixels they double again, and so on. If the pointing device moves in the "smaller" direction (west and/or north), the sizes halve after the first 100 pixels.

The BORDER_FACTOR_PER_PIXEL "constant" is the linear border scale factor used to change the drawing tool edge width. Its default value is 0.1/pixel. As the user drags the pointing device in the "bigger" direction (east and/or south, the +x and +y directions), the border width increases by 10 pixels for every 100 pixels of drag. If the pointing device moves in the "smaller" direction (west and/or north), the width decreases by 10 pixels for every 100 pixels of drag.

The DRAWING_COLOR "constant" is the color displayed by the drawing tool when it first starts up. The default value is opaque black (RGBA = 0, 0, 0, 255). The TEXT_CARET_COLOR "constant" is the color used to display the caret in editable text. The default value is opaque black (RGBA = 0, 0, 0, 255). The MAX_LABEL_WIDTH "constant" is the maximum size the layout algorithm is willing to assign to a text field or label. The default value is 250 pixels. The upper limit avoids problems with large text, which has no natural default size. The MIN_BTN_SIZE "constant" is the minimum size allowed for a button element. The default value is 16 pixels. The lower limit ensures buttons are "big enough" to push. The MIN_BORDER "constant" is the minimum size border that parent elements leave around their children during layout. The default value is 2 pixels. The MINJNNER "constant" is the minimum size allowed for the interior, active shape of an element. The default value is 4 pixels. The SELECT_COLOR "constant" is the color used to highlight text when it has been selected. The default is a mostly-transparent medium magenta (RBGA = 192, 0, 192, 32). The BUTTON_COLOR "constant" is the color used to outline radio buttons when they are "on" or selected. The default value is opaque red (RGBA = 255, 0, 0, 255). The DEFAULT_STYLE "constant" is the default text style used when no specific style is provided. The default value uses font family "Dialog", size 12 points, bold on, with an opaque dark navy foreground (RGBA = 102, 102, 153, 255).

Those skilled in the art will recognize that the method and apparatus of the present invention can be used for many applications. Moreover, the scope of the present invention covers conventionally known variations and modifications to the system components described herein, and such variations and modifications are intended to be within the scope and spirit of the present invention as defined by the following claims.

Claims

What is claimed is:

1. A graphic user interface comprising: a desktop display window for displaying a variety of items wherein said graphic user interface consists essentially of a single window; one or more active elements displayed on said single window wherein every item displayed on said single window is an active element, wherein said one or more active elements are drawn into said single window and wherein said every item is not independent from said single window; a configuration tool operable with said one or more elements wherein said configuration tool permits a user to alter the characteristics of said one or more active elements; and a view generator capable of generating active elements to display a single record view of an object or a multi record view of a group of like objects, said single record view and said multi record view are generated semi-automatically.

2. The graphic user interface of Claim 1 wherein said one or more active elements is a single element, a parent element, a child element, or both said parent element and said child element.

3. The graphic user interface of Claim 2 wherein said parent has one or more child elements.

4. The graphic user interface of Claim 3 wherein two or more child elements are adapted to permit overlapping with each other.

5. The graphic user interface of Claim 5 wherein one or more child elements are adapted to be moveable outside the boundaries of said parent.

6. The graphic user interface of Claim 1 wherein said one or more active elements have an active shape portion wherein said shape portion is selectable by a user.

7. The graphic user interface of Claim 6 wherein said active portion shape has zero or more borders that are changeable by a user.

8. The graphic user interface of Claim 3 wherein any of said child elements can be resized outside its parent's apparent boundaries.

9. The graphic user interface of Claim 1 further comprising a color selection tool.

10. A method of providing a graphical user interface wherein everything displayed on a screen is an active element, said method comprising: providing a computer display window wherein said display window consists essentially of a single window; drawing one or more active elements into said display window wherein said one or more active elements are one or more of a simple active element, a label active element, a text active element, and a button active element, wherein said drawing step includes: providing an initial rectangular size for each of said one or more active elements; and providing an active shape portion within each of said one or more active elements; and allowing each of said one or more active elements drawn on said single window to be moved, resized and configured by a user.

11. The method of Claim 10 wherein said drawing step further includes permitting each of said one or more active elements to be a parent element and a child element.

12. The method of Claim 10 wherein said drawing step further includes providing an active element configuration panel for each of said one or more active elements.

13. The method of Claim 11 wherein said drawing step further includes allowing said one or more child elements to overlap with each other.

14. The method of Claim 11 wherein said drawing step further includes permitting said one or more child elements to move outside of the boundaries of said parent element.

15. A method of providing a graphical user interface wherein everything displayed on a screen is an active element and wherein no active element is independent of said screen, said method comprising: display means for providing a computer display window wherein said display window consists essentially of a single window; drawing means for drawing one or more active elements into said display window wherein said one or more active elements are predefined by an any-to-any database or an automatic view generator and are one or more of a simple active element, a label active element, a text active element, and a button active element, wherein said drawing step includes: means for providing an initial rectangular size for each of said one or more active elements; and means for providing an active shape portion within each of said one or more active elements; and means for allowing each of said one or more active elements drawn on said single window to be moved, resized and configured by a user.

16. A computer program product for a computer, said program product comprising: a computer readable storage medium having computer readable program code means embodied in said medium for providing a graphical user interface wherein everything displayed on a screen of said computer is an active element and no active element is independent of said screen, said computer readable program code means comprising: computer readable program code means for causing said computer to effect providing a computer display window wherein said display window consists essentially of a single window; computer readable program code means for causing said computer to effect drawing one or more active elements into said display window wherein said one or more active elements are one or more of a simple active element, a label active element, a text active element, and a button active element, wherein said drawing step includes: computer readable program code means for causing said computer to effect providing an initial rectangular size for each of said one or more active elements; and computer readable program code means for causing said computer to effect providing an active shape portion within each of said one or more active elements; and computer readable program code means for causing said computer to effect allowing each of said one or more active elements drawn on said single window to be moved, resized and configured by a user.

17. The program product of Claim 16 further comprising computer readable program means in said program product for causing said computer to effect permitting each of said one or more active elements to be a parent element and a child element.

18. The program product of Claim 17 further comprising computer readable program means in said program product for causing said computer to effect allowing said parent element to have one or more child elements.

19. The program product of Claim 18 further comprising computer readable program means in said program product for causing said computer to effect allowing said one or more child elements to overlap with each other.

20. The program product of Claim 18 further comprising computer readable program means in said program product for causing said computer to effect permitting said one or more child elements to move outside of the boundaries of said parent element.