Abstract:
A method and apparatus are provided for integrating application programs and objects of the application programs in an integrated graphical user interface processing environment, such as a windows environment. The method and apparatus facilitate the integration without requiring modifications of the application program software, and without requiring that the application programs conform to any particular communication protocol. When a command input, such as a mouse click by a user in a windows environment, indicates that an object from one application is to be dropped onto a window in which another application is running, the properties of the window and the attributes of the object are used to search a rule database to identify a rule which is applicable to these particular types of object and application. The rule contains an action clause, which specifies various actions which are to be executed automatically, to invoke a desired operation by or related to the application program on the object. The action clause may include window event generating actions for simulating user input that invokes the desired operation by the application program, or actions that reference an external command file whose execution performs a desired operation related to the application program.

Description:
This is a continuation of application Ser. No. 07/987,230 filed on Dec. 08, 1992, now abandoned. 
    
    
     FIELD OF THE INVENTION 
     The present invention generally relates to the field of processor operation and management. More specifically, the invention relates to communication between different types of application programs and user interfaces with application programs. 
     BACKGROUND OF THE INVENTION 
     Most computer application programs dating back more than about a decade use a text-based user interface, in which the user types commands on a keyboard, and output from the application is displayed on a text screen. With the advent of computer interface technology that supports the displays of graphical images, Graphical User Interfaces (GUI&#39;s) have become popular. A GUI application can be controlled through menu bars, buttons, sliders, or similar control elements drawn by the application on the display screen. The user interacts with a GUI application using a pointing device, such as a mouse, to move a cursor across the display and clicking a mouse button while pointing at a menu or one of the other graphical controls provided by the application. 
     Window systems allow multiple applications to run side-by-side on the same display by dividing the screen into separate, possibly overlapping, rectangular areas (windows). Window systems typically support GUI applications as well as older, text-based applications running in a window that emulates a character terminal. Examples of such window systems are the Apple Macintosh operating system, the X-Window system under the Unix operating system, Microsoft Windows running under DOS, and the IBM OS/2 Presentation Manager. 
     Integrated Graphical User Environments go one step further by supporting a graphical mode of interaction between different applications running in different windows. Examples of such environments are integrated application packages, e.g., Computer Aided Software Engineering (CASE) systems, as well as so-called Object Oriented User Interfaces (OOUI&#39;s). In a OOUI environment the user interacts with the system by manipulating iconic representations of system resources (data files, application programs, printers or other I/O devices, etc) on the screen. For example, to print a document, the user moves the cursor to the icon representing the file containing the document, presses down a mouse button, moves the cursor to an icon representing a printer, and releases the mouse button. For another example, a user might initiate a text editing operation on a pre-existing text file by using the mouse as above to select a text file icon in a directory browser window, move the icon to a window in which a text editor is running, and release the text file icon onto the window. This type of interaction is called &#34;drag and drop&#34;, because an object selected in one window is &#34;dragged&#34; to another window where it is &#34;dropped&#34;. Examples of OO GUI environments are the IBM OS/2 2.0 Work Place Shell, as well as so called &#34;desktop managers&#34; available for DOS (Norton Desktop) and Unix (Xdt, HP-VUE, OpenLook, etc). 
     A drawback of these environments is that applications integrated in the environment must follow a specific protocol to interact with the other applications. Typically, communicating among application programs in a graphical user interface environment requires all programs to follow a pre-established protocol, such as the communications conventions of the Andrew Toolkit. Existing applications cannot be integrated into the environment without re-engineering and rewriting the application. Processes which do not follow the protocol, i.e., are not implemented with the specific interfaces, are left non-integrated. For instance, in the text editing example discussed above, if the directory browser program and the text editor program are not part of the same integrated package, then the directory browser will not know how to communicate that the user desires to edit a selected file to the text editor. Thus, the directory browser will not be able to initiate the desired operation by the text editor. 
     Therefore, how to integrate existing and new applications without requiring such imbedded interfaces has been a continuing problem, and users have had limited ability to integrate the different applications which their systems support. 
     U.S. Pat. No. 5,075,847, issued to Fromme and titled &#34;Method and Apparatus for Computer Program Encapsulation&#34;, describes a method for integrating a text-based application tool into a CASE system without modifying the application code. An interface description file specifies the layout of a graphical user interface for the application tool as well as the desired operations in response to interactions with the user interface and with other tools. However, the Fromme method is restricted to text-based applications only. As described in column 8, lines 49-53, 
     The application tools selected for encapsulation in accordance with the present invention must conform to the UNIX pipe model of communication. Communication with the application tool is in the form of character string inputs and character string outputs. 
     In the Fromme system, the user interface for the application, as specified in the interface description file, is created and controlled by the CASE system. The system uses the Unix pipe facility to control the application by sending commands as character strings to the standard-input stream (stdin) of the application and intercepting its standard-output stream (stdout) to display the output in a window created by the CASE system. Therefore, the Fromme method is unsuitable for integrating GUI applications into a graphical user environment, because such applications do not follow the UNIX pipe model. Rather, such GUI applications create their own user interface and cannot be controlled through stdin and stdout. 
     SUMMARY OF THE INVENTION 
     An object of this invention is to provide a method and apparatus for integrating existing text-based and GUI applications into an integrated graphical user environment without requiring the application code to be modified. 
     It is also an object of this invention to provide a method and apparatus for integrating an object, of or created by a first application having a first property, with a second application in a window, such that, to the user, the integration is carried out by a drag and drop operation. 
     To achieve these and other objects, there is provided in accordance with the invention a method for integrating applications into an integrated graphical user environment, such that, given an object from a first application having a first property, a second application having a second property performs an operation on, or otherwise integrates, the object from the first application. The method includes the steps of identifying a rule from a rule database which is compatible with the first and second properties, and which specifies an action for invoking the desired operation in the second application, and performing the action specified in the identified rule, thereby invoking the desired operation by the second application on the object. 
     A processing system according to the invention, supporting a plurality of application programs and objects, which have respective properties, includes a rule database containing a plurality of rules for integrating the application programs and the objects. 
     Each rule includes means for identifying which of the application programs and objects the rule applies to. In operation, an application program runs inside a window. The window has properties which reflect the properties of the application running inside the window. Therefore, in a preferred embodiment of the invention, the means for identifying includes a property of the object to be integrated with the application running in the window, and a window property. The identification is made by comparing the properties of the window and the object with properties specified in the rules. 
     Each rule also contains means for directing the processing system to invoke an operation by the second application compatibly with its property and the property of the object of the first application. 
     A computer program product according to the invention, for use with a processing system, includes a recording medium, such as a diskette, and means recorded thereon for directing the processing system to operate as follows. 
     Each rule also contains means for directing the processing system to invoke an operation by the second application compatibly with its property and the property of the object of the first application. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a system block diagram for a preferred implementation of the invention. 
     FIG. 2 is a flowchart showing the execution of a method according to the invention. 
     FIG. 3 is a list of selection clause keywords and formats for the rules in the rule database 10 of FIG. 1, according to a preferred embodiment of the invention. 
     FIGS. 4A and 4B together make up a list of action clause keywords and formats for the rules in the rule database 10 of FIG. 1, according to a preferred embodiment of the invention. 
     FIG. 5 is a table of macro symbols used with the keywords of FIGS. 3, 4A, and 4B, according to a preferred embodiment of the invention. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1 is a system block diagram of a processing system employing an integrated graphical user environment. In this particular example, the environment is a windows environment, and the window system function is provided by a windows server 2. FIG. 1 shows an example of how an application that was written for an integrated graphical user environment, shown as an enabled application 4, interacts with an existing, unmodified GUI application, shown as a foreign application 6. An application written for the environment, such as the enabled application 4, uses a software library 8 that encapsulates the mechanism of the present invention, in a manner to be described. 
     The following describes how the system of FIG. 1 operates when the user selects an object in the enabled application 4 and drops it onto a window containing the foreign application 6. How the user initiates a drag and drop operation depends on how the enabled application 4 was programmed, and could have many different forms. In an OO GUI, for example, the user moves the cursor to an iconic representation of an object drawn by the enabled application 4, such as a file, directory, or other system resource, and presses down a mouse button. Alternatively, the user chooses an item from a menu created by the enabled application 4. 
     In either case, the enabled application 4 receives messages from the windows server 2 describing the user interaction as a stream of window events (e.g., cursor movement, button presses, etc.). When the enabled application 4 recognizes that the user wants to initiates a drag and drop, it calls into the library 8, passing as a parameter attributes of the object selected by the user (e.g., if the selected object represents a file, the file name, file type, last-modified time, etc). If the windows events indicate that the foreign application 6 is the target of the interaction, i.e., if the user releases the mouse button to drop the object onto a window created by the foreign application, then it is necessary to integrate the object with the foreign application 6. The integration is accomplished through reference to a rule database 10, in a manner to be described. 
     FIG. 2 is a flowchart showing the operation which is executed, according to the present invention, when the enabled application 4 makes such a call into the library 8. In a first step 12, the library 8 monitors messages from the window server 2. In this particular case, the library 8 monitors the window event messages from the windows server 2. These window events include cursor motion, through the use of a mouse, and mouse button pushes. 
     In step 14, the window events indicate that the mouse button has been released. That is, the user has used the mouse to select a window on the display. In response, in step 16 the library 8 sends a message to the windows server 2 to determine which window is located at the cursor position where the mouse button was released. In this example, the user releases the mouse button over a window created by the foreign application 6. 
     Prior to having released the mouse button, the user had used the mouse to select an object, having certain attributes, from the enabled application 4. By releasing the mouse button on the foreign object 6, the user has indicated his desire to integrate the object from the enabled application 4 with the foreign application 6. The library 8 also sends additional messages to the windows server 2 to obtain window properties, such as the window name, defined for this window. From the window properties, the properties of the application running in the window may be inferred, so that integrating the object with the window, in accordance with the window properties, in effect facilitates integration of the object and the application. 
     After the library 8 obtains this information, it consults the rule database 10, in step 18. The library 8 searches the rule file for a matching rule. For the present, a general description of the rules will be given. A more detailed description of the rules, with examples, appears below. 
     Each rule contains a &#34;selection clause&#34; that specifies a set of conditions on window properties and object attributes. The selection clauses of the rules are examined, one by one, to compare the window properties and object attributes with those specified in the selection clauses of the rules. If the window properties obtained in step 14, as well as the attributes of the object selected by the user, satisfy these conditions, a matching rule is found and the search ends. Otherwise, the search continues by considering the next rule in the file. 
     Step 20 tests whether a matching rule was found. If no matching rule is found, then the library 8 detects an error condition (step 22) and returns control to the enabled application 4. In response, either no action is taken, or an appropriate action, such as displaying an error message, is taken. In one preferred embodiment, the error messages includes a return code stating the nature of the failure. 
     In addition to the selection clause, each rule contains an &#34;action clause&#34;. If a matching rule is found, the library 8 proceeds by executing the sequence of actions specified by the matching rule&#39;s action clause (step 24). An action may specify either (a) a window event or events to be sent to the foreign application 6, or (b) external programs or shell scripts to be executed. For example, in an X-Windows environment, in the former case (a), the library 8 sends an XSendMessage-message to the windows server 2 containing the specified X-event and the identity of the window of the foreign application 6. The windows server 2 then forwards the message to the foreign application 6. 
     In the latter case (b), the library 8 executes a system call to the operating system to load and start the specified program. For instance, a text file created by a first text editor includes imbedded text formatting commands as per the first editor. If the user drags and drops the text file onto a second text editor which employs different imbedded text formatting commands, the rule would include a call to execute an external program for converting the commands in the file as per the first editor to the appropriate commands as per the second editor. 
     The method according to the invention integrates objects and applications in a variety of ways. For a first example, if a directory browser and a text editor are running in two windows, and the browser and the editor are not part of the same integrated package, then the method of the invention may be used to allow the user to select an object out of the directory browser window and drop it onto the editor window, to edit the object. In cases such as this, the rule should be designed in such a way that the windows events sent to the foreign application 6 simulate a user interaction that invokes the operation intended by the user when he/she initiated the drag and drop. However, the application need not operate on the object in this manner. As another example, the object could be an editor profile. In this case, dropping the profile onto the editor window causes the editor to be configured as per the profile. As yet another example, a help icon could be selected from a first window and dropped onto a second window in which an application is running. As a result, a help message for the application is displayed. In these cases, the rule starts an external program to perform the desired operation. 
     The action clause may be thought of as a program in a programming language, whose execution integrates the object and the application. In cases such as (b), where an external program is executed, the program is written in a programming language, such as C. In cases such as (a), the action clause of the rule itself serves as a program. As will be discussed in detail below, the action clause is written in terms of keywords, which serve as a programming language. 
     A detailed description of the rules in the rule data base 10 according to the preferred embodiment of the invention will now be described. As stated above, each rule includes a selection clause and an action clause. In the preferred embodiment, each one of these clauses includes one or more of a plurality of keywords, each keyword having a specified argument. The keywords for the selection clause according to the preferred embodiment of the invention are shown in FIG. 3. As shown, one keyword, &#34;window&#34;, specifies a pattern for the name of the window on which the user has dragged and dropped an object. In an X-Windows environment, the keyword &#34;window&#34; is preferably the WM --  NAME property of the window. Persons familiar with the X-Windows environment will recognize WM --  NAME. From WM --  NAME, or other suitable window properties it is possible to infer the properties of applications within the windows. Therefore, according to the invention, the window properties are used for determining, by selection clause, which rule is appropriate to use to integrate an object with the foreign application 6. 
     Another selection keyword is &#34;type&#34;. As shown, the selection clause of the rule specifies the file type in accordance with the various symbols representing various file types. In a given situation in which a user has dropped an object of a particular type onto a particular type of window, the information regarding the window properties which the library 8 obtained from the server 2 in step 16 is compared against the selection clauses of the rules in the rule data base 10. In step 18, the rule data base search involves comparing the window properties and object attributes with the various patterns and file types specified in the selection keywords in each rule. Thus, a match is located, and the appropriate rule is identified. 
     FIGS. 4A and 4B together make up a list of action clause keywords and formats according to the preferred embodiment of the invention. As described above, once a match has been made between a rule in the rule data base 10 and the specified window properties and object attributes, the action specified in the action clause is executed to invoke the desired operation on the object. This is done by executing an existing program or shell script or by sending events. As shown in FIG. 4A, the &#34;exec&#34; keyword is used to specify the name of the external program to be executed. The directory within which this program executes is specified using the &#34;cd&#34; keyword. A sequence of keystroke events to be sent to the foreign application 6, such as a suitable keyboard command, is entered as a text string using the keyword &#34;string&#34;. Various control keys on a keyboard are specified as being pressed or released using &#34;key press&#34; and the &#34;key release&#34; keywords. Similarly, mouse button presses and releases are specified using the &#34;button&#34;, &#34;button down&#34;, and &#34;button up&#34; keywords. A time delay is specified using the &#34;wait&#34; keyword. By default, these events are directed to the window on which the user has dropped the object. The events may be directed to a particular window other than this default window by specifying the window using the &#34;pop up&#34; keyword. 
     Finally, a result of the operation is specified using the &#34;result&#34; keyword. Various result codes are shown in FIG. 4B. The result code is returned to the enabled application 4 from which the object was dropped. 
     Depending on the size of the rule data base, there may be more than one rule whose selection clause matches a given user operation. In such situations, the rules in the rule data base are ordered such that the rule whose action clause is normally to be executed should appear in the rule data base before any other rules whose selection clauses also match the given user operation. Alternatively, other suitable criteria are used to determine which of the matching rules is to be executed under which circumstances. 
     Given the keywords in FIGS. 4A and 4B, it will be seen that either an external program or one or more event generating actions such as window events (cursor moves, mouse button pushes, etc.) may be specified in the action clause. If it is desired that some combination of external program execution and event generating actions is to be used, then appropriate sequencing, such as arranging the keywords in the rule in accordance with the sequence in which the actions are to be taken, are employed. 
     According to the invention, an object may be dropped on either an existing window, having an application, or on a background window or into a default environment, such as the desktop. In these latter cases, there is no application to which window events cound be sent. However, a rule with an appropriate action clause (using the &#34;exec&#34; keyword) can be used to invoke a desired behavior such as starting up a new instance of a text editing program, in a new window, to edit the object. 
     Rules in the rule data base 10 may also be classified into groups based on whether the object is to be dropped on the desktop or on a window. This classification scheme also includes a separate class of default rules which are to be applied if none of the earlier rules are applicable. 
     In many instances, predefined rules which anticipate integrating certain types of objects and applications that are likely to be integrated often may be provided. For instance, a computer program product according to the invention, such as a diskette containing software for use with a processing system, may include a predefined table of rules. On the other hand, a user may want to customize rules for his or her own particular use. Therefore, the invention preferably includes a method or means for allowing the user to customize his rule database. Either the user edits the rule database 10 in its entirety, or the rule database 10 includes a preset rule database and also a separate user-writable rule database. 
     In the preferred embodiment of the invention, various symbols for the arguments of the various keywords are specified conveniently using macros. In FIG. 5 a table of predefined macros, identified by the symbol &#34;$&#34;, are given. 
     A few examples of rules will now be shown and described in detail. Reference to FIGS. 3, 4A, 4B, and 5 will enhance comprehension of these examples. 
     In the first example, the enabled application 4 is a directory browser, the foreign application 6 is the GNU-emacs text editor. When the user selects a file from the directory browser window and drops it on an emacs window, emacs should load the file so the user can edit it. The following rule in the rule database 10 will accomplish this: 
     
         window=[eE]macs.*type=F button=1 string=&#34;\033xfind-file\n$f\n&#34; 
    
     The selection clause of this rule is: 
     
         window=[Ee]macs.*type=F 
    
     It specifies that this rule is triggered if a regular file (&#34;type=F&#34;) is dropped on a window with a name that begins with &#34;emacs&#34; or &#34;Emacs&#34;. 
     The action clause (&#34;button=1 string=. . . &#34;) specifies a button-down window event for mouse button one followed by a sequence of key-press events to be sent to the emacs window. The &#34;$f&#34; macro stands for the name of the dropped file when the rule is triggered. These events will cause emacs to execute the &#34;find-file&#34; function to load the file. 
     Next, a variation of the first example will be shown, in which the emacs &#34;dired&#34; function is invoked when a directory is dropped on an emacs window. 
     
         window=[eE]macs.*type=d button=1 string=&#34;\033xdired\n$f\n&#34; 
    
     This example is similar to that shown above. The only differences compared to the other emacs rule are that the selection clause selects the rule only if a directory is dropped (type=d), and the action clause invokes the dired function instead of find-file. 
     In these first two examples, the foreign application can be driven entirely through keyboard events. Other applications require more complicated interactions involving menus and popup windows. In a third example, the enabled application 4 is a directory browser, and the foreign application 6 is the FrameMaker document preparation system. When the user selects a FrameMaker document in the directory browser window and drops it on the &#34;open&#34; button in the FrameMaker control window, FrameMaker should open a new edit-window allowing the user to view the selected document. 
     The following rule in the rule database 10 will accomplish this: 
     
         window=&#34;FrameMaker&#34; type=F button=1 wait=2 
    
     
         popup=&#34;FrameMaker--Open&#34; key=End key=CtrlBackSpace 
    
     
         string=$f key=Return 
    
     The selection clause specifies that this rule is triggered if a regular file (&#34;type=F&#34;) is dropped on a window named &#34;FrameMaker&#34;. The action clause first sends a button-down window event for mouse button one to the FrameMaker window. The FrameMaker application creates a window named &#34;FrameMaker--Open&#34; containing a text field in which it expects the user to enter the name of the document to be viewed. The action clause specifies to wait for this window to be created and then simulates the user clearing the text field and entering the name of the document. 
     While the preferred embodiments of the present invention have been illustrated in detail, it should be apparent that modifications and adaptations to those embodiments may occur to one skilled in the art without departing from the scope of the present invention as set forth in the following claims.