Customizable user interfaces for programmed computer systems5862395Abstract A software architecture is provided for allowing users to impart various types of button behavior to ordinary human interpretable elements of electronic documents by associating hidden persistent character string button attributes to such elements. This architecture permits such buttons to be edited and searched through the use of the edit and search routines that are ordinarily provided by standard document editors. Claims What is claimed: Description FIELD OF THE INVENTION
______________________________________
Poppy1
Class: PopUpButton
CommandHandler:Colorizer
Menu: (
((SetColor Red) "Red" "Makes selected objects red")
((SetColor Green) "Green" " Makes selected objects green")
((Set Color Blue) "Blue"" Makes selected objects blue")
)
Feedback: (
Enter: <SetCursor bullseye>
Down: (BeginButton MakeBold EndButton)
Exit, EndActivity: (BeginButton MakeItalic EndButton)
)
______________________________________
In the foregoing example, the first word, "Poppy1," means that what follows is a program in the Poppy language, version 1. As will be seen, it is followed by four button data fields: Class, CommandHandler, Menu, and Feedback. All buttons must have a Class field because a button's class determines which body of code (i.e., button handler) will handle user input to the button. In this case, the Class is "PopUpButton." The CommandHandler field identifies the command handler application 14 (FIG. 1) that will receive commands when a selection is made in this button's pop-menu by using the name under which that application is registered with the kernel 12. The command handler for the above button is a "Colorizer" application, which changes the color of selected objects to a color named in the button's menu. The Menu field in the above example describes a pop-up menu in a LISP-like syntax that the pop-up button class handler understands. This menu has three entries, labeled "Red," "Green," and "Blue." The text string following the entry labels is the documentation string that will be displayed when the cursor is over that entry. The parenthesized expression before each entry name represents a text string that will be sent to the application. The sub-fields of the Feedback field determine the actions that are to be taken when various button events occur. The "Enter" sub-field causes the cursor to change to a bullseye shape when it enters this button. The angle brackets around "SetCursor bullseye" tell Poppy to interpret this expression itself, rather than passing it to the editor that manages the button. The "Down" sub-field contains an expression string in the input language of the aforementioned Tioga text editor for causing the editor to apply a bold-faced font to the text of this button. Likewise, the "Exit, End Activity" field restores the button to a plain-face font when the button's application has finished its computation or when the user aborts the operation by moving the cursor out of the button before the click is complete. In the Poppy language, the value of each field is either a single alphanumeric string delimited by white space or a string (which can include white space) between standard delimiters such as quotation marks "", parentheses (), and angle brackets <>. When an editor reads a button-containing file from disk, it causes the Embedded Buttons kernel to parse the button attribute of each button. The kernel parses the button attribute string into a set of (field name)/(field value) pairs, where each field value is an uninterpreted string and passes those pairs to the appropriate button handler for the buttons class, thereby causing the class-specific button handler to build a run-time data structure representing the button. Multi-state buttons and radio buttons have two additional data fields--Name and Variables--which are expressed in Poppy as, for example: Name: Fruit Variables: (Value: {orange, apple, banana}=orange). In the above example, Value is a variable that may take on the values orange, apple, or banana, and its current value is "orange." Applications refer to this value, for purposes of reading or writing it, by using the button's name, "Fruit." If more than one button has the same name, the value of this button name could become ambiguous. Therefore, this problem typically is solved by forcing all buttons with the same name to have the same value, whereby changing the value of any one of them causes all of the others to change. Alternatively, however, it would be possible to look up the value of a given variable name in a particular sub-part of a hierarchically structured document. For instance, if a button, A, refers to a value by a variable name, N, the system could look for the value of the variable N first in the paragraph in which A occurs, next in the sub-section in which A occurs, next in its section and so on. In this way, the hierarchical structure of documents can be used to disambiguate names. 2. Editor Characteristics. The editors 11 (FIG. 1) may need to be modified in a few simple ways in order to participate in the embedded buttons architecture. In particular, they should have routines to: a. enumerate all elements in the document that have the button attribute. b. describe the button attribute (and other attributes) of a given document element. c. edit the document in accordance with editing commands provided in an editor-specific command language (optional). d. report whether a given cursor position is inside or outside of a given document element. In addition, for improved performance, an editor may additionally embody a routine that: e. associates a pointer to an arbitrary data structure with a document element. Also, some buttons require that the editor: f. describe the contents of a button as a text string. This last mentioned feature makes the most sense if the button is embedded in a text document. Finally, the editors must be able to delay the processing of selection actions (e.g., pointing with a mouse or using cursor keys) when they are in a "button mode" until they have determined whether the document element under the cursor at any given point in time possesses a button attribute or not. If such an attribute is found, the editor takes no editing action. Instead, it passes along to the embedded buttons kernel the information that the mouse button was depressed while the user was pointing to an embedded button. On the other hand, in the absence of such an attribute, the editor performs whatever editing action it normally performs when a mouse button is depressed over the given document element. Fortunately, these features are generally easy to implement. All mouse-based document editors already contain code for determining the document element to which the user is pointing. Furthermore, most such editors have code fore dispatching to an appropriate routine to handle each input event, and all WYSIWYG (What You See Is What You Get) editors have code for accessing the attributes of document elements. Therefore, they are easily extended to include code to determine whether or not the button attribute is present, to dispatch to the embedded button kernel when appropriate, to modify these attributes, and to search for document elements that have particular attributes. 3. The Embedded Buttons Kernel. The Embedded Buttons kernel provides two types of routines: (1) Registration procedures that allow new command handlers, button classes, and application windows to become known to the system. (2) Action routines that contribute to the use of buttons by users and software routines. The basic routines of each of those types are described in this section. a. Registration Procedures. A message handler suitably registers itself with the embedded buttons kernel by calling a kernel routine: RegisterMessageHandler: PROCEDURE ›name: String, notifyProc: RegisteredNotify:Proc!; where "String" is an ASCII text string, and "RegisteredNotifyProc" is a procedure of type: RegisteredNotifyProc: TYPE=PROCEDURE ›action: String, button Button! RETURNS ›success: BOOLEAN!. In this "RegisteredNotifyProc" "button" describes the embedded button that was pressed to trigger the action and BOOLEAN is a true/false value. Consequently, when the kernel reads a button attribute that requests that an action be sent to a command handler having a registered name, the kernel calls the associated RegisteredNotifyProc, thereby passing the action request to the command handler as a parameter. A button class registers itself with the embedded buttons kernel by calling the kernel routine: Register ButtonClass: PROCEDURE ›buttonClassName: String, buttonClass: ButtonClass!; where ButtonClass provides routines for performing the following procedures: (1) Instantiate. Create run-time data structures for a given button of a specified class from its button attribute. (2) File Out. Produce a revised button attribute for the given button (e.g., if its value has changed since it was created) from its run-time data structure whenever the button's host document is written to disk. (3) Handle Triggering. Respond to triggering actions the given button. This routine decides what feedback should be performed and when the command handler should be notified. (4) Get Value. Report the current value of the given button when the kernel inquires about it. (5) Set Value. Respond to requests to change the value of a given button. Buttons may respond, for instance, by changing their run-time data structures and by producing appropriate human-visible feedback. (6) Default Behavior. Perform the behavior the given button should exhibit if it has no specified command handler for it. For instance, buttons with state often change to the next state when triggered if no command handler is specified. When an application wishes to link a particular document to a particular application window, it calls: LinkDocToApplication: PROCEDURE ›doc: ActiveDoc, handlerName: String, window: Window, applicationData: POINTER, notifyProc: NotifyProc!; where "ActiveDoc" represents the virtual memory address of the button-containing document that is to be linked. Once the above routine is called, the kernel subsequently is able to handle triggering on any button in "ActiveDoc" whose command handler field contains the same "handlerName," by calling "notifyProc" and passing it the arguments "window" and "applicationData" to cause the button's action to be performed. In that event, "window" describes the particular application window whose contents should be affected by triggering the given button, and "applicationData" is a pointer to any other information that the application will require in order to carry out the intended button action.To that end, "notifyProc" is a procedure of type: NotifyProc: TYPE=PROCEDURE ›button: Button, action: String, window: Window, applicationData: POINTER! RETURNS ›success: BOOLEAN!; The success return value of this "notifyProc" is used by the buttonclass to determine (when providing user-visible feedback that the button action is completed) whether to indicate to the user that the requested action has succeeded or failed. b. Action Routines The kernel's action routines are called by editors that manage button-containing documents, by application programs that use documents as control panels, and by button classes for helping the kernel to respond to calls made by such editors and application programs. In particular, the kernel provides three routines that are called by the editors of button-containing documents: HandlePress, DataStructureFromAttribute and AttributeFromDataStructure. Furthermore, the kernel provides two basic routines that are called by applications: GetValue, and SetValue. Finally, the kernel provides six basic routines that are called by button classes: PassEventToCommandHandler, GetField, SetField, GetAttribute, SetAttribute, and RegisterNameValuePair. These routines and their functions are defined in this section. 1. Action Routines Called by Editors HandlePress: PROCEDURE ›press: InputAction, button: Button, doc: ActiveDoc!; is one of the more fundamental routines in the embedded buttons architecture. An editor calls this routine when it discovers that the user has moved a cursor over a button and triggered the button (be that by clicking a mouse button, pressing a keyboard key or by some other means). The argument "press" is a representation of the method used by the user to trigger the button. Some buttons (e.g., pop-up buttons) behave differently depending on the physical key or keys that are depressed to trigger it, so that information is included in the "press" argument. The "button" argument describes which button was triggered, and the "doc" argument describes the document in which this button is located. When "HandleClick" is called, the kernel parses the button attribute to discover what button class should handle this click and passes the action to that button class for further processing. Another routine that the editor may call is: DataStructureFromAttribute: PROCEDURE ›attribute: String, button: Button, doc: ActiveDoc! RETURNS ›dataStructure: POINTER!; In order for the HandlePress routine to succeed, the kernel must parse the button attribute. It could do this parsing every time the button is triggered, but this would adversely affect performance. Instead, the editor can call the DataStructureFromAttribute routine once for each button at the time that the document is loaded. This routine parses the button attribute, builds a data structure to represent the button and returns this data structure to the editor. The editor can then store this data structure in place of the button attribute string as a run-time value of the button attribute. ›Note: As an extra enhancement, the parsing can be done the first time the button is pressed, so that the cost need not be payed at the time the document is loaded for all of the buttons. With this scheme, the parsing cost is only payed for those buttons that are used. When the document must be written to disk, a button attribute data structure can be turned back into a string using the AttributeFromDataStructure routine: AttributeFromDataStructure: PROCEDURE ›dataStructure: POINTER! RETURNS ›attribute: String!; As will be seen, this routine takes a data structure of the form produced by the above-described DataStructureFromAttribute routine and turns it into a human-readable text string in the Poppy language. Editors call this routine when a document is being written to disk so they can represent the button attributes externally as text strings. Note that, for a particular button, the text string returned by this routine may not be identical to the text string that was passed to DataStructureFromAttribute as an argument. For instance, if the button is a multi-state button, its value may have changed from TRUE to FALSE and this new state will be reflected in the revised button attribute string. 2. Action Routines Called by Applications GetValue: PROCEDURE ›name: String, doc: ActiveDoc! RETURNS ›value: String! is a routine that returns the value of the variable named Value as it appears in the button or buttons in document "doc" that have the given text string "name" in the "Name:" field of their button attributes. If several buttons exist in this document with this name, then this routine returns the value of the first such button encountered. To improve performance, the GetValue routine checks to see if "name" has been registered by RegisterNameValuePair (see below) in a hash table. If so, it finds the associated value very quickly and returns it. Otherwise, with the help of the EnumerateButtons routine described in Section D.2. routine, it searches through all of the buttons in the document looking for the name and returns a value if the name is found. If no such named button is found, it returns the empty string. SetValue: PROCEDURE›name: String, value: String, doc: ActiveDoc!; This procedure changes the value of the variable Value in all buttons in the document "doc" that have the given name. It also passes the button name, value, and doc to RegisterNameValuePair (see below) so that future calls to GetValue will produce the correct value quickly.3. Action Routines Called by Button Classes PassEventToCommandHandler: PROCEDURE ›event: String, button: Button, application: String!; is called by a button class to inform the kernel that it is time to pass the text string called "event" to the command handler of the named button. The kernel determines from the button and the kernel's current tables of registered command handlers and linked documents (see the above-described LinkDocToWindow routine) which procedure to call to notify that command handler, then passes the event to that procedure, and finally returns. GetField: PROCEDURE ›fieldName: String, button: Button! RETURNS›field: String!; is a routine that returns the value of a particular field of the button attribute of a given button. For instance, if GetField›"CommandHandler" is applied to the multi-sate button for the above-described Colorizer application, it would return the string "Colorizer". SetField: PROC›fieldName: String, field: String, button: Button!; is a procedure for assigning a new value to a particular field of a button attribute. Subsequent GetField operations on the changed field will return the new value. GetAttribute: PROC›key: String, button: Button! RETURNS ›pointer: POINTER!; While the button attribute (identitified by letting key be "ButtonAttribute") is the only attribute of a document element that is essential to the embedded buttons architecture, some button classes may wish to get the values of other attributes. For instance, the Buttonizer button described herein uses a second attribute (identitified by letting key be "ButtonAttributeLiteral"). The GetAttribute procedure makes all of these attributes available to the button classes. This routine returns a pointer to an arbitrary data structure, so the button class must know whether this data structure is a text string or some other data structure in order to make use of it. SetAttribute: PROCEDURE›key: String, pointer: POINTER, button: Button, edited: BOOLEAN!; allows the button classes to change the value of any attribute of the document element described by the "button" argument. RegisterNameValuePair: PROC ›name: String, value: String, doc: ActiveDoc!; is a routine for storing the pair (name, value) in a hash table using "name" as the key. As will be recalled, the GetValue routine uses this table to quickly find the values of those named buttons that have stored their names and values in this table. 4. The Button Classes. As described in section c.2 above, at least three different button classes are supported from the point of view of the user of a button-containing document, these classes provide three basic building blocks for interfaces made from documents. Furthermore, as described in section D.3.a, the set of button classes can be extended (even at run-time) by calling a registration procedure. Moreover, it will be recalled that each button class is defined by six procedures, also described in section D.3.a. In addition, a button of a of a given button class will have different fields in its button attribute to support its activity. This section contains examples of button attributes for all three of the above-described button classes, and describes how each class implements its six routines. a. Pop-Up Buttons. Pop-up buttons may display a pop-up menu when they are triggered (depending on the manner in which the user triggers them), and they perform an action based upon the menu item the user selects. For instance, the button attribute for a pop-up button that opens the file named in the text of the button itself as in FIG. 2C (this button attribute must be associated with a textual document element for this action to make sense) is as follows:
______________________________________
Poppy1
Class: PopUpButton
Menu: (
((<Concat "Open" <ButtonText>>) "Open" "Opens the file
represented by this button")
CommandHandler: CommandTool
Feedback: (
(Mouse Moved <SetCursor bullseye>)
)
______________________________________
The PopUpButton class requires the field "Menu." The Class, CommandHandler, and Feedback fields are supported by the Embedded Buttons kernel, for all button classes. The six basic routines for the pop-up button class are implemented as follows: Instantiation. This routine reads the Menu field and creates a data structure representing the graphical appearance of the pop-up menu. File Out. As this button attribute has no values, it does not change during use. The file out routine simply returns the original button attribute. Button Press. First, the embedded buttons kernel 12 (FIG. 1) is requested to perform any feedback associated in the Feedback field with the button being pressed. Next, the pop-up menu is drawn on the user's display screen (if the user holds down the mouse button long enough to warrant the display), and the user is then allowed to make a menu selection. If the user made a selection, that selection is evaluated. For instance, in the above example, the expression <Concat "Open" <ButtonText>> would be evaluated, thereby finding the filename mentioned in the button's text and prepending the string "Open" to it. For instance, if the button was the text string ".about./writings/diary," the concatenation would produce the string "Open .about./writings/diary." Finally, the kernel 12 passes this text string to the command handler (the "CommandTool" in this example). The command handler 14 then performs the action (e.g., displays the named file on the screen). Finally, the kernel 12 calls upon the editor to perform any feedback that is provided to show that the button command has completed. Get Value. There is no value, so this procedure does nothing. Set Value. There is no value, so this procedure does nothing. Default Behavior. If there is no command handler, pop-up buttons simply display their command on the screen for the user to read. This is useful for debugging buttons of this class. b. Multi-State Buttons. FIG. 5B illustrates a multi-state textual button that can have the value TRUE or FALSE. When its value is TRUE, the text appears white on black. When FALSE, the text appears black on white. Its button attribute is:
______________________________________
Poppy1
Class: MultiStateButton
Name: GridOn
Variables: (Value: BOOL = TRUE)
UpClickMessage: (Toggle Grid)
CommandHandler: Picture Region
Feedback: (
(Down (BeginButton ClearLooks LookItalic End Button))
((Value TRUE) (BeginButton ClearLooks LookWhiteOnBlack
EndButton))
((Value FALSE) (BeginButton ClearLooks EndButton))
______________________________________
Multi-state buttons require that the "Variables" field appear in their button attributes and that a variable, called "Value," be defined. Additionally, it should be noted that the field called "UpClickMessage" in the above example describes the message to send to the command handler when the user finishes clicking on this button. The field "Name" is supported by the embedded buttons kernel; it gives the kernel a way to refer to the value of this button. The other fields, Class, CommandHandler, and Feedback are supported by the Embedded Buttons kernel for all button classes. The Multi-State button class implements its six class specific routines as follows: Instantiation. This routine reads the Variables field and creates a data structure representing each named variable and its value. It also ensures that the button initially has the correct appearance by performing the feedback associated with the current value of Value. For instance, in this example, the button would send the string "BeginButton ClearLooks LookWhiteOnBlack EndButton" to the text editor, which makes the text of the button look normal (as a result of the ClearLooks command) except that it is white on black (as a result of the LookWhiteOnBlack). The BeginButton and EndButton commands in this example tell the text editor to apply the other commands to the text of this button, rather than to some other part of the document. File Out. To describe itself textually, a multi-state button must construct a new value for the Variables field by writing out the name and current value of each variable mentioned in the original button attribute. In this example, this involves writing out the string "TRUE" or "FALSE" depending on the current value of the variable, Value. The other fields of the button attribute do not change and are written outjust as they were read in. Button Press. First, the kernel is requested to perform any feedback associated in the Feedback field with the button being pressed. In the above example, the feedback line beginning with "Down" specifies that the button should be displayed in italics when the user clicks down on it. When the user releases the mouse button (or otherwise indicates that a selection has been made) the message "Toggle Grid" is sent to the command handler. If this expression contained procedure calls (such as <ButtonText> or <Concat> in the pop-up buttons example), such procedures would be called at this time. Get Value. This routine returns the value of the variable Value. Set Value. This assigns the new value to the variable Value and performs the feedback associated with the new value. For instance, in the foregoing example, if Value is set to FALSE, the edit instruction "BeginButton ClearLooks EndButton" would be sent to the text editor, thereby causing the button to become black on white text. Default Behavior. If there is no command handler, and the user completes a selection of this button, the UpClickMessage field is ignored. Instead, Value is cycled to its next possible value. For instance, in our example, each click would change this value from TRUE to FALSE or FALSE to TRUE. c. Radio Buttons. FIGS. 7A and 7B illustrate a pair of radio buttons that could be embedded in a graphical editor. As will be seen, the circle (FIG. 7B) is thicker than the square (FIG. 7A) to indicate that the circular button is "on" while the square button is "off". The button attributes for these two buttons are nearly identical. More particularly, the attribute for the square button is:
______________________________________
Poppy1
Class: RadioButton
CommandHandler: DrawShapes
Name: Shape
RadioButtonValue: Rectangle
Variables: (State: BOOL = FALSE)
UpClickMessage: (RectangleMode)
Feedback: (
((State TRUE) ((BeginButton) (LineWidth 5.0) (DashesOff)
(EndButton)))
((State FALSE) ((BeginButton) (LineWidth 2.0) (DashesOff)
(EndButton)))
(Down ((BeginButton) (Dashed) (EndButton)))
(UP ((BeginButton) (DashesOff) (EndButton))
______________________________________
In the button attribute for the circular button, the boldface word "Rectangle" in the above example would be replaced by "Circle," and the boldface word "FALSE" would be replaced by "TRUE". As will be seen, the RadioButton class supports the fields RadioButton Value, Variables, and UpclickMessage. The RadioButton Value field describes one possible value of the variable Value, which is not mentioned explicitly in the button attribute but which is defined implicitly by all of the radio buttons that have the same name. For instance, in the foregoing example, Value can take on the values of the set {Rectangle, Circle}. Variables and UpClickMessage, on the other hand, have functions similar to their functions for multi-state buttons. However, for radio buttons, the variable State must be defined and must be a BOOLEAN (TRUE/FALSE) value. Moreover, the State value may be TRUE for only one button in a set of radio buttons. All radio buttons in a group have the same Name field. The other fields, Class, CommandHandler, Name, and Feedback are supported by the Embedded Buttons kernel for all button classes. Radio buttons implement their six class procedures as follows: Instantiation. This routine reads the Variables field and creates a data structure representing each named variable and its value. It also ensures that the button initially has the correct appearance by performing the feedback associated with the current value of State. For instance, in the above example, the square button would send the editor interpretable string "(BeginButton) (Line Width 2.0) (DashesOff) (EndButton)" to the graphics editor, which makes the square look thin and undashed. Likewise, the circular button would send the interpretable string "(BeginButton) (LineWidth 5.0) (DashesOff) (EndButton)" to the editor, thereby causing the editor to make the displayed circle thick and undashed. File Out. Just like a multi-state button, a radio button must produce a new string to represent its Variables field. The other fields do not change and are written out as the same string that was read in. Button Press. As before, the kernel first is requested to perform any feedback associated in the Feedback field with the button being pressed. In the above example, the feedback line beginning with "Down" specifies the selected button should be rendered a dashed shape when the user clicks down on it. When the user releases the mouse button (or otherwise indicates that a selection has been made) the message "RectangleMode" is sent to the command handler. If this expression had contained procedure calls (such as <ButtonText> or <Concat> in the pop-up buttons example), these would have been called at this time. Get Value. The Get Value routine for radio buttons is interesting. The value of a related group of radio buttons is the value of the RadioButtonValue field of the one button of the group whose State variable is TRUE. Thus, in the above example, Get Value would return "Circle". Set Value. Set Value is also interesting. The Value specified must be the value of the RadioButtonValue field of one of the buttons in the group. This button's State variable is set to TRUE and the State variables of all of the other buttons in the group are set to FALSE. Each variable executes the appropriate feedback for its new state (buttons that did not change state need not execute any feedback actions). Default Behavior. If there is no command handler, and the user completes a selection of a radio button, its UpClickMessage is ignored. Instead, the State value of the selected button is set to TRUE, and all other buttons in its group have their State variables set to FALSE. Feedback is performed as described for the Set Value routine. 5. The Command Handler When a button is triggered, a command is sent to a command handler application 14 (FIG. 1) to perform a predetermined function. Each button describes which command handler 14 will receive each command by naming that handler as part of the command or in the "CommandHandler" field of the button attribute. In fact it is possible to send commands to several command handlers by listing their names in the CommandHandler field. New command handlers can be added to the software system on-the-fly.1). Any program can call the RegisterCommandHandler procedure to register a command handler name and call-back procedure with the EmbeddedButtons kernel 12 (FIG. 1) Subsequently, the kernel 12 will handle all commands directed to a registered command handler name by calling its registered call-back procedure. The call-back procedure, in turn, takes two arguments: a command, and a description of the button being pressed. Moreover, it returns an indication of whether or not the command succeeded, thereby permitting different feedback to be provided to the user in the case that a command fails. Advantageously, the system includes at least the following basic set of command handlers 14 (these handlers provide support for a wide range of button behaviors): a. The CommandTool Command Handler. The CommandTool command handler interprets its command argument as though it had been typed by a user to, say, a Cedar command shell. The Cedar command shell works much like the command shell in UNIX inasmuch as any output from the command shell is written to a special typescript that is shared by all of the embedded buttons. b. The Buttonizer Command Handler. The Buttonizer command handler applies a button attribute to a user-selected document element. More particularly, the button attribute that is applied is taken from a special, otherwise-unused attribute called the "ButtonAttributeLiteral" of a so-called Buttonizer button. As will be appreciated, this approach makes it just as easy to alter the button attribute of the buttons that are created through the use of such a Buttonizer button as to edit the behavior of the Buttonizer button itself because both behaviors can be altered by editing an attribute of the Buttonizer button. For instance, here are the attributes of a Buttonizer button for producing pop-up buttons:
______________________________________
ButtonAttribute: Poppy1
Class: PopUpButton
Menu: (
((Selected) "Buttonize" "Applies the ButtonAttributeLiteral
property of this button to the selected text")
)
CommandHandler: Buttonizer
ButtonAttributeLiteral: Poppy1
Class: PopUpButton
Menu: (
((Event1) "First Item" "Sends Event1 to application")
((Event2) "Second Item" "Sends Event2 to application")
)
______________________________________
The ButtonAttribute attribute describes the behavior of this button itself. The ButtonAttributeLiteral attribute, on the other hand, becomes the ButtonAttribute of the newly created button. Therefore, in this particular case, the new button will have a pop-up menu with two elements. Furthermore, this pop-up button will send its commands to a command handler called "Message Window." c. The Message Window Command Handler. The message window command handler simply prints out the command in a special region of the display screen that is reserved for feedback so that the user can read it. This command handler is especially useful for debugging new buttons. d. The Document Editor Command Handler. The document editor command handler sends the button's command string to a suitable document editor, such as the aforementioned Tioga editor. The commands in this text string are generally used to edit the document in which the button appears or the document that contains the current user-selected document elements, but they could be employed to edit any document. As will be appreciated, this command handler allows buttons to be used to trigger document editor macros. For instance, a pop-up button with the button attribute:
______________________________________
ButtonAttribute: Poppy1
Class: PopUpButton
Menu: (
((ApplyLook Bold) "Bold" "Make selected text bold")
((ApplyLook Italics) "Italics" "Make selected text italic"))
CommandHandler: Document Editor
______________________________________
causes the document editor editor to make selected text objects bold when the first menu item is selected, or italic when the second menu item is selected. 6. The Editor Input Language. The first example in section D.1 shows the button attribute for a button that changes its text's appearance to bold while it is active and back to plain face when it is idle. This font change is accomplished by sending the command strings "BeginButton ApplyLook Bold EndButton" and "BeginButton RemoveLook Bold EndButton" to the document editor. Similarly, the button described in section D.5 performs an editor macro on whatever text string the user has selected. While it is not strictly necessary for a document editor to be able to interpret an input editing language, embedded buttons become much more useful when this capability exists. Given such an editor, the user can include document editing strings as sub-strings of a button attribute for invoking standard document editor operations to display feedback and to perform macro operations in a particular document editor. 7. Handling Button Presses. FIG. 8 illustrates the communication paths that are used when the user triggers an embedded button. These communication paths are used in several steps as follows: Step 1: Notification (Editor 11 to EmbeddedButtons) Kernel 12 to specified Button Class 13). When the user clicks, say, a mouse button on an embedded button, the editor 11 that manages the document containing the embedded button passes the mouse action, a description of the embedded button's position in the document, and its button attribute to the Embedded Buttons kernel 12. The kernel 12, in turn, reads the "Class" field of the button attribute to route the above information to the button handler for the specified Button Class 13. Step 2: Initial Feedback (Specified Button Class 13 to Embedded Buttons kernel 12 to Editor 11). If appropriate, the button class 13 asks the Embedded Buttons kernel 12 to perform any feedback actions associated with this mouse action. For instance, a button might draw a box around itself when the mouse enters it, or might gray itself when the mouse clicks on it. The kernel 12 looks up the mouse action in the "Feedback" field of the button, and passes any commands that it finds to the editor 11 that manages the button. Step 3: Choosing an Action (Specific Button Class 13) to Embedded Buttons kernel 12 to (Command Handler 14). At this point, the button class may pop up a menu of actions or simply wait for the mouse button to come up. Once the user has chosen an action for this button to perform, the button class 13 may request more feedback to show that an operation is in progress (see Step 2). Then, the button class 13 sends the chosen action list to the kernel 12. The kernel looks up the name in the "CommandHandler" field of the button attribute, and passes the action list to the command handler routine 14 that is registered under that name. Step 4: Final Feedback (Specified Button Class 13 to Embedded Buttons kernel 12 to Editor 11). Once the command handler 14 has finished performing the action that was triggered by the button, the button class 13 asks the editor 11 (via the kernel 12) to perform some final feedback (e.g., returning the embedded button to its original appearance. As shown in FIG. 8, the software system resides in virtual memory 21 of a more or less conventional computer system 22. For example, the computer system 22 suitably includes a bus 23 for linking a central processing unit (CPU) 24 to the virtual memory 21 via a memory controller 25, to a keyboard 26 and a cursor controller (e.g., mouse) 27 via an I/O controller 28, and to a monitor 29 via a display controller 30. However, it is to be understood that the present invention may be applied to computers having other architectures because the invention is not dependent on the architecture of the host computer 22. 8. Getting and Setting Button Values. Multi-state buttons and radio buttons both contain values that can be queried by an application program. Handling these types of buttons requires two complications to the mechanism described in section D.3.b. First, it should be possible for an application program to find out the current value of one of these buttons. In that connection it will be recalled that the embedded buttons kernel 12 provides a routine, GetValue, that takes an active document and a button name as arguments and returns the value of the button as a text string. Fortunately, whenever an application is using an active document as its control panel, the application has a pointer to this active document, so making this procedure call is straightforward. As will be appreciated, the kernel 12 may dynamically register such an active document as a named command handler 14 for the application in response to a routine registration request made by the application. Second, the state changes of the button may need to be synchronized with other application actions. Consider a drawing program that uses an active document to set the value of the current color. The user should be able to set the color to red, draw a shape, set the color to blue, and draw a second shape, even if the application has gotten behind and has not finished displaying the first shape at the time when the user changes the current color to blue. To prevent confusion, the button (or buttons) that change the current color should not change the value that they report, until the application is done using the current value. To make this synchronization possible, multi-state buttons and radio buttons do not automatically change state. Instead, they send to the application a request to change state. When the application is ready, it calls the routine, SetValue, to set the button to the new value. This leads to a fifth step in input handling: Step 5: Changed Value Feedback (Application to Embedded Buttons kernel to Editor). When an application calls SetValue, the embedded buttons kernel 12 looks in the "Feedback" field of each button whose value has changed for a feedback action to perform. If one is listed, this action is sent to the editor 11 that manages the button. Preferably, in order to respond quickly when applications ask for the value of a named button, the embedded buttons kernel 12 maintains a hash table (a standard computer science data structure. See Don Knuth. The Art of Computer Programming, Volume 3) of values, where the hash table key is derived from the variable name of the button, and the value stored in the table is current value of the button. One such hash table is maintained for each currently active button-containing document, and that table is updated each time a named button variable within the document to which the table pertains changes its value. 8. Linking Documents to Application Windows. In many systems, a given application may be running in several windows at once. However, operations in the control panel of a given window are intended to apply to the contents of that window, and not to the contents of any other window. In addition, some windows have multiple panes. Furthermore, different buttons in a given control panel may be intended to apply to different panes. Thus, to generalize the use of button-containing documents as control panels, the embedded buttons kernel 12 provides the aforementioned LinkDocToApplication routine that can be called by an application for linking a CommandHandler name in a given active document to a particular pane of an application window. For instance, a mail reading program may use one pane for displaying message headers, and another pane for displaying message bodies. A button that applies to the headers then stores "CommandHandler: Headers" in its button attribute, while a button that pertains to the message body stores "CommandHandler: Bodies" in its button attribute. In this case the link routine would be called twice, once to link the "Headers" buttons and once to link the "Bodies" buttons. Note that the buttons themselves are not linked to the application panes. Rather, the CommandHandler name to which they refer is linked. This makes it possible to add new buttons to the control panel at run time that will be automatically linked to the document containing the correct panel when they mention the correct CommandHandler. Conclusions In view of the foregoing, it will be understood that systems that allow buttons to be embedded in documents provide the following capabilities: (1) By using the buttons that are embedded in documents, readers can act on the information in the document using facilities in the document itself; this integration allows users to stay focused on their tasks, and saves screen space that would otherwise be used for tools "off to the side" of the document. (2) Wherever systems exist for sending structured documents through the mail, buttons can be sent through the mail as well, allowing users to easily exchange useful buttons and to respond quickly to the information received in the electronic mail. (3) Users can copy pieces of existing control panels into new documents to create customized control panels. In addition, the button architecture described herein provides these additional advantages: (4) Buttons can be edited through the use of standard editing document operations, because they are ordinary document elements. (5) The actions performed by the buttons can refer to the contents or appearance of the button itself, and hence to any properties that the document editor supports. Thus, buttons can be used to modify their own appearance or to transfer their properties to other objects in the same document editor. (6) Buttons can have any shape. In many systems, the buttons must be rectangular. But, in the system described herein, the buttons are arbitrary document elements and their shapes are limited only by the capabilities of the editors in which they are embedded. (7) Because such a button is represented simply as an additional string attribute on a document element, button-containing documents can be generated through the use of existing software for generating structured documents. A more detailed review of the aforementioned advantages of this invention follows. 1. Staying Focused on the Task. Often an electronic document is read to find information that the user intends to put to use immediately. For example, when a user enters a command to list the files in a directory, the user often desires to read, rename, or delete some of the files in the list. In most current interfaces, the user's attention must be diverted from the list to a command shell or file tool to open an editor window on one of the listed files. If, however, the file names are buttons, as they are in some Symbolics applications, these operations can be performed directly on the file list, without diverting attention from the list. As another example, software modules may include a set of buttons near the text of each routine for testing the routine, timing its performance, or providing hypertext links to places where that routine is further documented, implemented, or called. 2. Buttons in the Electronic Mail. The sender of an electronic mail message may wish to include buttons that help recipients act on the information in the message. For instance, when sending a message describing a software release, a phone number, or a file, the sender might include a button to install the new software, dial the phone number, or open the file, respectively. 3. Reusing Control Panels. As previously described, sets of buttons can be linked to a particular pane of an application window, allowing button-containing documents to act as control panels. If control panels are documents, document editors can be used to navigate through them, to modify them, to copy them, and to combine parts of them into customized control panels for special tasks. For example, FIG. 9A shows a dialog box that searches for text patterns. It is set to search for the bold word Apple, and replace it with italic word Banana. In FIG. 9B, this control panel has been copied into a document. To save space, a hider button called "Parameters" has been used to encapsulate the control panel shown in FIG. 9A. (A hider button hides inside of it a small document; when the hider button is pressed, it reveals the small document.) The Search, Yes, No, and Substitute buttons shown in FIG. 9B provide functions for performing replacements either one-by-one or all at once. Together these buttons form a compact control panel for a specific search task (searching for Apple and replacing it with Banana). To change the parameters, the user can expose and use the hidden control panel (FIG. 9A). 4. Document Skills Become User Interface Skills. Conventional document editors can create, select, move, copy, delete, store, retrieve, search for, scroll through, change the style of, selectively display, and print document information. When documents are user interfaces, all of these capabilities become available both for creating and employing user interfaces. Moreover, the familiar layout capabilities of document editors can be used to compose control panels. Graphical editors can be used to create borders and icons, and text editors can be used to lay outlines or tables of buttons with appropriate colors, fonts, underlining and so forth. Such control panels inherit the ability of text editors to reformat text for different page sizes and scaling factors. For interface users, document editors provide ways to navigate through the user interface. Users may build large documents, organized into sections and sub-sections, containing many buttons, computed fields, and other active elements to aid them in a variety of tasks. These users can then take advantage of scrolling, level-clipping (e.g., displaying header names only), and textual or graphical search to find user interface components. Textual search-and-replace and graphical search-and-replace (See D. Kurlander et al., "Graphical Search and Replace," Computer Graphics, Vol. 22, No. 4, August 1988, pp. 113-120) can be used to quickly make user interfaces from existing documents. For instance, a document of names, addresses, and phone numbers can be turned into an active document by searching for strings that look like phone numbers and turning them into buttons that dial the phone number. 5. Customizing Document Editors. Just as the capabilities of document editors can be used to improve user interfaces, button-containing documents can be used to enhance document editors. This reinforcing cycle can result in rapid improvements in both document editors and user interfaces. For example, users can create button collections that perform tedious or complicated text editor operations, including text searches and style changes. One particularly useful embodiment of such a button, which is called a "stuffer," inserts its own textual contents at the current text editor cursor position. Buttons can also be used to improve document navigation. One example, inspired by the GUIDE hypertext system (P. Brown, "A Simple Mechanism for Authorship of Dynamic Documents," J. C. van Vliet (ed), Text Processing and Document Manipulation, Proceedings of the Internal Conference, Cambridge University Press, April 1986, pp. 35-42) is the ability to hide a portion of a document behind a button. With each button press, the text is alternately revealed and hidden. Such hider buttons allow the user to browse through a document using screen space only for document parts of interest. Note that a document with hider buttons can be used as a layered control panel. See FIGS. 9A and 9B. Buttons can be used in unusual ways to customize a graphics editor. FIGS. 10A and 10B show a collection of circles drawn with an illustration program. It will be assumed that the user would like to try different colorings of these circles. That could be carried out by employing normal editor commands to select each circle in turn and apply a color to it, but that would take several mouse clicks for each color change. It is significantly easier to turn each circle into a two-state button that is, say, black when on and white when off. In that event, the color changes can be made with one mouse click per color change. When all such changes have been made, the button activity can be turned off (or the button properties can be removed from the shapes) leaving a recolored picture that can one again be edited normally. 6. Buttons Can Have Any Shape. Any cursor-based editor, be it for text, graphics, equations, tables, etc., has a way to detect which object the user is pointing at. The button attribute architecture takes advantage of these facilities to tell when the user is pressing a button. Thus a button can be a circle, a triangle, a gingerbread man, a fancy lace pattern, or any shape so long as the document editor in which the button is embedded can detect when the user is pointing at that shape. Recall FIG. 4A, which shows that a button can even be a single line segment in a system where the user need only point near an object rather than exactly at it. 7. Generators. One of the more important properties of the embedded buttons that are contemplated by this invention is that they can be created and modified by users through the use of familiar document editor operations for most of the steps of the process. However, it is also useful to be able to generate embedded buttons automatically under program control. For instance, a command that lists all of the files in a directory might add the button attribute to the file names, turning the file names into buttons that open the corresponding file when pressed. Using the architecture of this invention, the capability to generate button-containing documents by program requires no special programming. The system need only provide a way for programs to generate structured documents with arbitrary attributes on their document elements. This capability is already present in systems like Digital Equipment Corporation's CDA architecture which allow data, called "private data," that is restricted to a particular document-processing implementation to be associated with standard document elements. See the CDA (Compound Document Architecture) Manual, Digital Equipment Corporation, Maynard, Mass., November 1988, Section 3.1.5.6. Given such a structured-document generator, all that is needed to generate buttons is to attach an attribute called "ButtonAttribute" when creating those parts of the document that are to behave as buttons.
|
Same subclass Same class Consider this |
||||||||||