Graphical resource editor for software customization

Abstract

A graphical resource editor for selectively modifying graphical resources in software applications provides a main window graphical user interface object for interaction with the graphical resource editor. The main window contains a resource category selection object including a list of selectable resource category objects. These objects contain resource category descriptors corresponding to categories of editable resources. The resource category selection object provides a user activatable interface for selecting among the list of resource category objects an editable resource category. The graphical resource editor further includes a system responsive to user activation of the resource category selection object for generating in the main window a list of resource descriptors corresponding to selected category of editable resources. A plurality of resource value display fields are provided in the main window for displaying resource values representing the status of the selected category of editable resources. Also provided in the main window is a set of resource value selection objects providing user activatable interfaces for setting editable resource values. Customization of software applications may performed statically by saving resource edits to an application resource file, or dynamically by applying resource edits on-the-fly to an application running concurrently with the graphical resource editor.

Claims

We claim:

1. In an application resource editor for customizing graphical resources of a software application executing concurrently with the application resource editor in a data processing system, a method for dynamic customization of the software application comprising the steps of:

displaying a list of resources in said software application that are capable of modification;

determining from user input an application resource to be modified from said list of resources and a resource value representing an attribute of said resource to be modified;

searching a list of resources in a resource database maintained by said software application and identifying matching resources in said resource database corresponding to said resource to be modified; and

applying said resource value to each matching resource in said resource database in order to change the values of said matching resources and thereby customize said software application.

2. In a data processing system, the data processing system having a data processing unit, a video display terminal, a keyboard, a cursor control system including a screen cursor and a user actuatable cursor positioner for providing control inputs to the data processing system, a data storage resource, and a graphical user interface system through which software applications running on the data processing system generate one or more graphical window objects on the video display terminal to provide user interaction functionality for the software applications, the appearance and behavior of the graphical window objects being partially determined by resources, a graphical resource editor for dynamically modifying selected resources in a software application running concurrently with the graphical resource editor in the data processing system, comprising:

means for displaying a list of resources in said software application that are capable of modification;

means for determining from user input an application resource to be modified from said list of resources and a resource value representing an attribute of the said resource to be modified;

means for searching a list of resources in a resource database maintained by said application and identifying matching resources in said resource database corresponding to said resource to be modified; and

means for applying said resource value to each matching resource in said resource database in order to change the values of said matching resources and thereby customize said software application.

3. A graphical resource editor computer program product for dynamically modifying selected resources in a software application running concurrently with the graphical resource editor product in a data processing system, the data processing system having a data processing unit, a video display terminal, a keyboard, a cursor control system including a screen cursor and a user actuatable cursor positioner for providing control inputs to the data processing system, a data storage resource, and a graphical user interface system through which software applications running on the data processing system generate one ore more graphical window objects on the video display terminal to provide user interaction functionality for the software applications, the appearance and behavior of the graphical window objects being partially determined by resources, the graphical resource editor product comprising:

a data storage medium adapted to store digital information readable by said data processing system;

means stored on said data storage medium for displaying a list of resources in said software application that are capable of modification;

means stored on said data storage medium for determining from user input an application resource to be modified from said list of resources and a resource value representing an attribute of said resource to be modified;

means recorded on said data storage medium for searching a list of resources in a resource database maintained by said application and identifying matching resources in said resource database corresponding to said resource to be modified; and

means recorded on said data storage medium for applying said resource value to each matching resource in said resource database in order to change the values of said matching resources and thereby customize said software application.

Description

BACKGROUND OF THE INVENTION

The present invention relates generally to the customization of graphically-controlled software in a data processing system. More particularly, the invention pertains to an editing system for selectively modifying resources used by software applications to provide graphical user interface objects.

A graphical user interface is a window-based system for interfacing with a programmed computer by means of graphical display windows. Such systems are ideally suited and conventionally adapted for menu-driven operation. That is, they allow a user to control computer operation by selecting from one or more menus exhibited in the graphical display windows without entering statements in alphanumeric form via a keyboard. A graphical display window is an area of the computer's physical display screen containing a collection of interface objects through which software applications running on the computer receive inputs and present their output. An interface object, such as a menu selection item, is a graphics- and/or text-based image that signifies information, function, and/or data entry. Such objects include push buttons, scroll bars, dials, sliders and many other graphical indicia. An interface object can be "selected" by moving a mouse-controlled pointer or cursor to it and operating (i.e., pressing or releasing) a button on the mouse. This selection process includes what is referred to in the art as "point-and-click". The interface object is supported by code that assists in providing appropriate response to the user's selection.

It is conventional for software applications to run in their own graphical display windows, the appearance and characteristics of which are defined by the application software. Each application employs one or more top level windows that define corresponding graphical display areas used by the application. In so-called "multitasking" operating systems, there may be several applications, each using one or more windows, sharing the screen together. To minimize confusion, these windows can be moved to different positions on the screen, and may also be resizable. Moreover, the windows are assigned a stacking order such that overlapping windows do not compromise window appearance. Higher order windows simply cover lower level windows in the area of overlap. Thus, the effect is that of sheets of paper arranged on a desktop.

One of the implications of a shared-screen, multitasking window environment is that the graphical display windows must provide a visually distinctive appearance that helps users control the sometimes complex functionality presented on the physical screen. Users may also have special requirements, apart from multitasking considerations, for ensuring particularized window characteristics. In the art of graphical user interfaces, the term "resources" refers to color, text fonts, screen cursors and other graphical attributes users may desire to control. Resource values are chosen by application developers during program development and may not represent an ideal choice when the application is implemented on a user's data processing system. Accordingly, it would be desirable to allow users to override or modify resource selections made by application programmers so that users are able to customize efficiently the look and feel of their applications.

In some operating environments, user customization of window resources is intended. The X Window System is an industry-standard software system developed at Massachusetts Institute of Technology that provides a window environment for developing device-independent graphical user interfaces. In the X Window System, resources defining attributes of graphical interface objects are set by program developers in an application-specific file known as an "app-defaults" file. The X Window System allows users to override resource settings in the app-defaults file with a user-generated file known as an ".Xdefaults" file. When an application is invoked, the X Window System, in an initializing step, creates an resource database and loads it with resource specifications found in the application's app-default file and the user's .Xdefaults file. The resource database is used by the application to build its windows and graphical interface objects at run time.

In the X Window System, as in other graphical user interface systems, graphical interface objects are defined hierarchically. For applications based on the X toolkit intrinsics, each graphical interface object is constructed from one or more components known as "widgets". A widget is an object oriented programming entity containing data and one or more functions which operate on that data. When created by an application, a widget is assigned its own screen window. There are various standard widget sets available to application developers for building graphical user interfaces. Open Software Foundation, Inc. provides the Motif toolkit. Widgets in the Motif toolkit include scroll bars, title bars, menus, dialogue boxes and a host of other graphical interface objects.

In app-defaults and .Xdefaults files, the resources used by widgets are specified using hierarchical string identifiers that uniquely determine the widgets (or widget classes) to which they apply. These identifiers can include such information as the name (or class) of an application containing the widgets. Moreover, because widgets in an application's graphical display window are defined hierarchically, the resource identifier can include a list of widgets (or widget classes) arranged in the widget hierarchy. The syntax of these identifiers must be observed or the resource may not be correctly applied to the intended widgets (or widget classes). As a result, manipulating an .Xdefaults file can be cumbersome and time consuming.

In response to this dilemma, efforts have been made to develop editors for the X Window System that allow users to customize their applications. One such product is "Editres" from Massachusetts Institute of Technology. Editres is an editing tool that allows users to view the full widget hierarchy of any application that speaks the Editres protocol. Editres assists the user in constructing resource specifications and allows the user to apply the resource to an application and view the results dynamically. If the user is satisfied with the resource modification, Editres appends the modified resource string to a selected app-defaults file or to the user's .Xdefaults file.

Despite its beneficial features, Editres suffers from several disadvantages. For example, some applications require source code modifications or recompilation in order to work with Editres. In the dynamic editing mode, Editres fails if it cannot communicate with the application. Editres also tends to overcomplicate the editing process by presenting the user with an entire widget tree containing every widget used by an application. Often, the user is not interested in more than a relatively small number of editable features. Moreover, it does not hide system window mechanisms from the user. Editres also does not provide editors directed to selected resource types. Resources are presented without regard to their relationship with resources of similar type, such as colors, fonts, etc. Nor are resources explained. Finally, Editres is language dependent because it requires the user to modify resources using an application's internal widget and resource strings. These are based on pseudo-English programming terms. This is undesirable for users who are not English speaking, or who are not familiar with resource string syntax, or who may not even understand the purpose and function of particular resources.

Another available resource editor is the Motif Resource Editor (MRE) from Open Software Foundation, Inc. MRE provides a system for editing resources using editing mechanisms that group resources by type. One editing mechanism modifies color resources. Another editing mechanism modifies font resources. Still other editing mechanisms modify filename and boolean resources, respectively. MRE allows editing selections to be appended to selected app-defaults files or to the user's .Xdefaults file. A disadvantage of MRE is that there is no provision for dynamic editing of concurrently executing applications. Moreover, no graphical interface is provided. Nor does MRE hide internal window mechanisms from the user. Finally, the MRE editor is language dependent and is not internationalized.

Accordingly, despite previous efforts to facilitate the efficient customization of software applications, the art still lacks a customization tool that overcomes the deficiencies outlined above. What is needed is a graphical resource editor providing a fully internationalized graphical interface to customization that frees the user from the conventions of resource specifications and the details of internal window mechanisms. The resource editor should operate with all applications, both old and new, without source code modifications or recompilation. It should allow static modification of selected resource files as well as dynamic modification of concurrently executing applications. The editor should group resources by type and provide dedicated interfaces for each resource type. Finally, because applications can have thousands of resources, a mechanism should be provided selecting a set of resources representing desirable or likely features for customization while maintaining an ability to add additional resources as desired.

SUMMARY OF THE INVENTION

The present invention is directed to a graphical resource editor that provides an opportunity for users to selectively modify resource values of interest in a highly efficient way. In a preferred aspect, a main interface window provides a graphical user interface object for interaction with the graphical resource editor. Within the main window is a resource category selection object including a list of selectable resource category objects. These objects contain resource category descriptors corresponding to categories of editable resources. The resource category selection object provides a user activatable interface for selecting among the list of resource category objects an editable resource category. The graphical resource editor further includes a system responsive to user activation of the resource category selection object for generating in the main window a list of resource descriptors corresponding to a selected category of editable resources. A plurality of resource value display fields are also provided in the main window for displaying resource values representing the status of the selected category of editable resources. There is further provided in the main window a set of resource value selection objects providing user activatable interfaces for setting editable resource values. Customization of a client application may be performed statically by saving resource edits to a resource file, or dynamically by applying resource edits on-the-fly to an application running concurrently with the graphical resource editor.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic illustration of a data processing system incorporating a graphical resource editor of the present invention.

FIG. 2 is a diagrammatic illustration showing a portion of a graphical resource editor of the present invention.

FIGS. 3A and 3B collectively provide a flow diagram showing process flow in a graphical resource editor of the present invention.

FIG. 4 is a block diagram showing source files, data types and widgets used by a graphical resource editor of the present invention.

FIG. 5 is an illustration of a graphical resource editor start-up menu.

FIG. 6 is an illustration of a graphical resource editor customizing menu.

FIG. 7 is an illustration of a sub-part of the menu of FIG. 6.

FIG. 8 is an illustration of a graphical resource editor filing menu.

FIG. 9 is an illustration of a graphical resource editor help menu.

FIG. 10 is an illustration of a graphical resource editor color browser.

FIG. 11 is an illustration of a graphical resource editor fonts browser.

FIG. 12 is an illustration of a graphical resource editor pictures browser.

FIG. 13 is an illustration of a dialogue box selected through the pictures browser of FIG. 12.

FIG. 14 is an illustration of a graphical resource editor cursors browser.

FIG. 15 is an illustration of a graphical resource editor choices browser.

FIG. 16 is an illustration of a graphical resource editor filenames browser.

FIG. 17 is a block diagram illustrating communications invoked during "on-the-fly" application customization.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

SYSTEM CONTEXT

It will be understood and appreciated by those skilled in the art that the inventive concepts set forth herein, pertaining to the provision of a graphical resource editor in a digital processing system, may be embodied in a variety of system contexts. One such system is illustrated by way of example in FIG. 1, wherein a data processing system designated generally as 10 includes a data processing unit 20, a video display terminal 30, a keyboard 40, and a cursor control system including a screen cursor 50 and a mouse 60 providing a user actuatable cursor positioner for providing control inputs to the data processing system 10. The data processing system 10 further includes data storage resources including a floppy disk drive 70, a hard disk drive 80 and local volatile memory (not shown) utilized by the data processing system to execute programs and control various hardware and software entities of the system.

The data processing system 10 may be selected from any of a number of conventional processor devices, including, but not limited to, processors commonly found in that class of data processing apparatus known as work stations. The preferred operating environment of the graphical resource editor of the present invention is the X Window System from MIT. As indicated above, the X Window System provide a device-independent, network-transparent, graphics windowing system including an application program interface for data processing systems. The X Window System is designed to be operating system independent, but is most commonly used with the UNIX and AIX operating systems. The X Window System is based on a client-server model wherein software applications requiring graphical output to a graphical display terminal utilize the services provided by a server having control of the graphical display terminal. The "X client" and "X server" represent software entities which may reside on discreet hardware platforms or may operate at a single work station or other data processing system.

In the data processing system of FIG. 1, the X server is designated by reference number 100 while the X client is designated by the reference number 110. The X server 100 manages inputs from the keyboard 40 and the mouse 60. It manages the video display 30 in order to process graphical output information from the X client or client application 110 and display it in a designated window such as the window 120 on the display. At the same time, the X server 100 may be managing other windows 130, 140 and 150 in the display. These windows can represent the outputs of other client applications or may represent interface windows for controlling the data processing system 10 itself.

The X server 100 assigns windows to applications desiring graphical output, and also provides window positioning and resizing services. Other window management tasks are performed by the client applications assigned to the windows. The server communicates user generated events to client applications and the client applications return information to the X server for performing necessary actions in their client windows. These communications between the X clients and the server follow a well-defined protocol known as the X protocol. The programming components implementing the X protocol are shown in FIG. 1 by reference number 160. Communication using the X protocol is directed through a network interface 170 which allows the client application 110 to be located at a remote platform, or within the data processing system 10, without affecting the client-server relationship. The X protocol is an asynchronous byte stream protocol providing an interprocess communication mechanism that defines the meaning of data exchanged between the client and server. The X server interprets the X protocol byte stream from clients and generates graphics output.

In order to facilitate the task of writing client applications, the X Window System provides a library of C language routines known as Xlib. The Xlib is shown in FIG. 1 by reference number 180. The Xlib provides access to the X protocol through several hundred or more utility routines for generating graphics primitives. These routines can be utilized directly by the client application 110 as shown in FIG. 1. In addition to the Xlib, the X Window System provides a higher level set of functions known as the X toolkit intrinsics. The Xt intrinsics provide a set of utility functions for building graphical user interface objects by calling Xlib functions to construct necessary graphical elements. The Xt intrinsics are illustrated by reference number 190 in FIG. 1. In addition to the Xt intrinsics the X Window System supports various "toolkits" which provide a library of graphical interface objects (known as "widgets" and "gadgets") which applications can use in constructing graphical user interfaces. The Motif toolkit from Open Software Foundation, Inc. provides a comprehensive set of widgets (and gadgets) constructed using Xt intrinsics and Xlib functions to provide graphical interface objects. As indicated above, widgets are object-oriented programming entities containing data and functions that operate on the data. Gadgets are similar to widgets but do not receive their own window when invoked. In the system of FIG. 1, the X toolkit (Motif) widget library is illustrated by reference number 200. A client application 110 can utilize widgets provided by the X toolkit 200 or can utilize the Xt intrinsics 190 or the Xlib 180 to construct its own widgets.

As discussed above, widgets form the building blocks used by applications to construct graphical user interfaces. Widgets are related to one another in a widget hierarchy beginning with a top level shell widget corresponding to the top-level window created by the X server for the application. All subsequent widgets of an application emanate from the shell widget. Each subsequent widget created by an application is assigned a corresponding window by the X server. Applications with graphical user interfaces generated under the X Window System are thus characterized by parallel hierarchies of windows and widgets.

In FIG. 1, the display 30 generates a plurality of graphical display windows 120, 130, 140 and 150. As indicated, each of these windows corresponds to a client application communicating with the X server 100. Each of these windows contains one or more widgets generated by the client applications. The widgets in turn, utilize application "resources" to specify window characteristics such as background and foreground color, the appearance of text fonts, the shape and configuration of screen cursors and other graphical attributes of the windows. In the X Window System an application resource can be any user-customizable parameter that affects an application's behavior or appearance. Application resources are stored in application-generated app-defaults files and the user's .Xdefaults file. These files are maintained in directories which may be accessed through the data processing system 10.

GRAPHICAL RESOURCE EDITOR OVERVIEW

In accordance with the present invention, the graphical resource editor is incorporated in the data processing system 10. The graphical resource editor provides users with the capability to access application resources and selectively modify the resources to change one or more attributes of an application's graphical user interface. This capability includes editing concurrently running applications "on-the-fly" so that the effects of resource changes can be viewed instantaneously. FIG. 2 illustrates some of the functional characteristics of the graphical user interface with respect to an application to be modified. The graphical resource editor generates a custom interface window 300 on the data processing system display 30, the features of which are shown generally by reference number 300. The custom interface window 300 includes a menu for selecting editable resources and for specifying resource values. For some resource value types, such as colors, the graphical resource editor provides browsing editors, such as the color editor 310, for controlling a wide range of resource values. The browsing editors are implemented as pop up windows that are selectable from the main customization window 300. Where no longer required, these windows are deleted from the screen.

It is not uncommon for applications running in the X Window System to employ hundreds of widgets whose the attributes are defined by an even greater number of resources. Because it is both undesirable and unnecessary to edit all such resources, the graphical resource editor of the present invention utilizes a resource filter mechanism to specify only resources that are desirable to edit. This filtering mechanism is implemented through a custom data file which will be referred to as an "app-custom" file. An app-custom file is illustrated in FIG. 2 by reference number 320. It is intended that app-custom files will be generated for each application to be used with the graphical resource editor. In addition, a user can create a default app-custom file to be used when an application specific app-custom file is not available. The information contained in the app-custom file is used by the graphical resource editor to build the custom interface window 300 based on customization information contained therein.

In FIG. 2, the graphical resource editor is used to modify the resources of "client" application having a graphical user interface 330. The resources utilized by this application can be modified in two ways. First, resource edits can be stored in the user's .Xdefaults file 340. In addition, if the client application is running concurrently with the graphical resource editor, resource edits can be provided to the application "on-the-fly" using a communications protocol 350, described in more detail below. Using the protocol, the client application can be updated without being restarted. For permanent storage of resource edits, however, the changes must be saved to the user's .Xdefaults file.

FIGS. 3A and 3B illustrate process steps taken by the graphical resource editor of FIG. 2 during a resource editing session. The editing process starts in step 400 when the user commences execution of the resource editor. In step 410, the user selects an application to customize and the resource editor attempts to establish communication with the application for the purpose of instantaneously updating it and then locates the app-custom file for that application. In process step 420, the resource editor locates and parses the app-custom file so that the resource information contained therein can be applied to the resource editor's custom interface window 300. The next step 430 in the graphical resource editing process is to create the custom interface window 300. This step includes a first step 440 of creating a window menu bar and a step 450 of creating resource selection objects. These interface objects are conventionally formed using combinations of widgets available in a widget library such as the Motif toolkit. They are generated using resource information from the app-custom file. In step 460, the resource editor builds editor widgets as necessary upon a user request for editor services. In step 470, the resource editor generates "save as" and "help" panels upon user selection from the menu bar.

With the custom interface window 300 established, the resource editor reads the user's .Xdefaults file (or specified app-defaults file) in step 480 and applies resource values to appropriate resource selection objects in the custom interface window. The resource editor is now ready for user interaction. This user interaction is processed by the graphical resource editor in step 490. Usually, this results in one or more editor widgets being generated by user requests for editor services. In cases where the application to be customized is running concurrently with the resource editor, the user may request that the application be updated on-the-fly. In step 500, the resource editor responds to such a request by applying resource edits as they are made via a communication protocal between the resource editor and the application to be customized. Following completion of an editing session, the user is prompted to save resource modifications to the user's .Xdefaults file (or a specified app-defaults file). The user may also discard the resource edits. The resource editor responds to the user's selection in step 510 and the editing session is terminated in step 520.

Turning now to FIG. 4, the source and header files, data types and editor widgets used by the resource editor in a preferred embodiment are shown diagrammatically. A preferred version of the graphical resource editor has been constructed using the C programming language, although other languages might also be used. In accordance with conventional C language programming techniques, the graphical resource editor uses main source and header files 550 that control the process flow described above in relation to FIGS. 3A and 3B. In addition to the main source and header files 550, the graphical resource editor uses a standard header file 560 containing global definitions used by other source files. Communications source and header files 570 are used for on-the-fly communication to identify the window id of the top level window of an application to be customized. Help source and header files 580 are provided to support the resource editor help facility. Message source and header files 590 provide a resource editor message facility supporting pop up windows containing messages regarding operation of the resource editor. Messages to be displayed by the message facility are placed in a message catalog file portion of a custom file 600. The default colors, fonts, etc. for the resource editor are stored in an app-defaults file portion of the custom file 600. The app-custom parser 610 contains files built using the UNIX/AIX parser-building tools "Lex" and "Yacc". The parser is used for locating and parsing app-custom files corresponding to applications to be customized. As described in more detail below, this parsing process uses information in the app-custom file to generate global structures referred to as the custom list and the custom group. Main interface source and header files 610 are used to create the custom interface window 300. The main interface source file uses the data type files 620-700 to generate to appropriate graphical interface objects corresponding to the different resource types identified in the app-custom files. The data type source files contain the functions and callbacks for each resource data type.

The .Xdefaults source and header files 710 are used to read and save to the user's .Xdefaults file (or other specified resource file) and apply resource values therein to appropriate menu locations in the custom interface window 300. The editor widget files 720-760 are used to generate, respectively, a color editor, a font editor, a cursor editor, a select many editor and a pixmap editor in response to user interaction with the custom interface window 300. Finally, the "on-the-fly" source and header files 770 provide an event handler that allows concurrently executing client applications to communicate with the graphical resource editor. These files are linked to the client application during client application linking.

GRAPHICAL RESOURCE EDITOR DETAILED FUNCTIONAL DESCRIPTION

A preferred graphical resource editor will now be described in the context of its detailed functional and operational characteristics which, as outlined above, are preferably implemented in an X Window graphical user interface environment. Persons skilled in the art of programming in the X Window System will appreciate from the ensuing description of editor functions that the invention can be implemented in a variety of ways using conventional X Window commands and functions, all of which are extensively documented.

Start-up of the graphical resource editor is achieved by typing the command "custom" together with one or more command line descriptors in accordance with the following UNIX/AIX command format:

custom {-h}{-e Editor/{-s filename}{Application}}

Command line help may be obtained using the -h option. The -e option allows individual browser editors to be invoked on a stand-alone basis. As described in more detail below, the resource editor provides a color browser, a fonts browser, a cursors browser, a select many browser and a pixmap browser. The -s option provides way to specify a resource file from which to read in and save resources and values. The default is the user's .Xdefaults file. The Application option allows user to identify an application to be customized. The user may also specify standard AIX/UNIX windows command-line options such as -fg for setting foreground color, -bg for setting background color, and other commands. These commands are processed by conventional X Window functions.

Following entry of the "custom" command, the graphical resource editor generates a start-up window 800 in the display 30 of the data processing system 10. Like all of the windows, fields, panels and other graphical objects generated by the graphical resource editor, the appearance and function of the start-up window 800 is determined by combinations of widgets (and gadgets) built from an X Window widget library such as the Motif library, together with application-defined callback functions that respond to user input events occurring in the widget windows. The start-up window 800 includes a scrollable application list window 810 containing a list of applications available for customization. A resource file containing the name and class of each listed application, and the name and class of their corresponding app-custom files, is used by the graphical resource editor to generate the information in the window 810. Below the application list window are three text fields representing three options by which applications can be selected by the user. The first option utilizes a push button interface object 820. This option is used when an application to be customized is running concurrently on the data processing system 10. The user activates the push button 820, moves the mouse cursor to a window used by the application of interest and activates the mouse in that window. A window searching procedure is used to identify the application to be customized and to display its name in the display field 830 of the start-up window 800. If the application name is the one desired, the user can select the application using the "OK" push button 840. The window searching procedure is built using the Xt convenience function XtAppNextEvent(). This function traps events reported by the X server and places them in a data structure known as the Xevent union. The X server event reports include information about mouse events. By querying the Xevent union, the custom application obtains an identification of the window in which the mouse pointer is positioned during mouse activation. From this information, the name and class of the client application can be readily determined. The second option for selecting an application is to choose from the list of applications in the application list window 810. When an application is selected its name appears in the display field 830 and can be accepted by selecting the "OK" push button 840. The third option for selecting an application is to simply type in the application name in the display field 830 and select the "OK" push button 840. Following the selection of an application to be customized, the graphical resource editor commences a communications protocol, described in more detail below, in order to establish communication with the application for the purpose of instantaneously updating it in "on-the-fly".

The application selection procedure occurs in process step 410 of FIG. 3A. In process step 420, the resource editor searches along predetermined search paths for the application's app-custom file. The app-custom file must have been previously generated by the application programmer or by the user prior to editing the application. If no app-custom file exists for the application, a default app-custom file is used. This can be provided with the resource editor package or generated by the user. If the default app-custom file cannot be found or if there is an error in a selected app-custom file, an error message will be displayed in a pop up window. The start-up window 800 also includes a "Cancel" push button 850 and a "Help" push button 860. The "Cancel" push button allows the user to cancel an application selection and begin again. The "Help" push button 860 is used to generate a pop up window containing help information for using the start-up window 800.

Once a customizable application is selected and its app-custom file, or the default app-custom file, is found, the app-custom file is parsed as described above in regard to process step 420 of FIG. 3A. The parsing process extracts information from the app-custom file that is used to generate the resource editor's custom interface window 300. As shown in FIG. 6, this interface window is formed by a main window 900 providing a graphical user interface object for interaction with the graphical resource editor. Within the main window 900 is a menu bar window 910 containing a series of pull down menus designated "File", "View", "Options" and "Help". Below the menu bar window is a main form window that contains an arrangement of selection objects providing a menu of editable resources. One such menu item is represented by a resource category selection object 920 that includes a selection push button 930. The resource category selection object 920 contains a resource category descriptor label identifying a category of editable resources displayed concurrently in a scrollable window panel 940. The resource category selection object is supported by a callback function which generates, in response to a user pressing and holding a mouse button while the mouse pointer is on the selection push button 930, a cascading list of resource category descriptors beginning with the resource category descriptor originally contained in the resource category selection object. The resource category descriptors correspond to categories of editable resources. The resource category selection object allows the user to select an editable resource category by dragging the mouse pointer over the list and releasing the mouse button when the pointer is positioned on a resource category of choice. A callback function associated with the selection object 920 responds to this operation by causing the scrollable window 940 to display another set of resources to customize. The resource category selection object 920 thus provides a user activatable interface for selecting among a list of resource category objects an editable resource category.

Inside the scrollable window 940 is a list of resource descriptors 950 corresponding to a selected category of editable resources. The scrollable window 940 further includes a plurality of resource value display fields 960 representing the status of the selected category of editable resources. In addition, the scrollable window panel 940 includes a set of resource value selection objects 970 providing user activatable interfaces for setting editable resource values.

The information displayed in the custom interface window 300 is determined from the client application's app-custom file. The app-custom file is a character string file containing character strings arranged in the following format:

Group Type Resource Name [Values]

The "Group" identifier is used to organize similar resources. For example, "scroll bar color", "on/off scroll bar", and "number of scrolled lines to save" are all different resource types but they are related. The "Group" parameter can be any character string in any language. These character strings constitute the resource category descriptors that will be placed as labels in the resource category descriptor object 920. The resource category descriptor "General" in the resource category descriptor object in FIG. 6 identifies a group of resources corresponding to the general attributes of an application. Resources may be grouped in any manner desired by the user.

The "Type" parameter specifies whether the possible values of a resource should be limited to colors, fonts, or other value types. This parameter is used to generate an appropriate resource value selector object 970 for specified resources contained in the resource descriptor list. The resource editor provides graphical tools that assist in setting a valid value to the corresponding resource value type. For example, colors are set using a color browser editor while fonts are set using a fonts browser editor. Other resource value types such as choices and numbers, are set in different ways, as described in detail below.

The "Resource" parameter is the actual resource string of the resource file to be modified by the editing process. This parameter obeys the X Window resource specification syntax such that resources are listed exactly as they would be in the .Xdefaults file, except that they are not prefaced by an application name or class. This information is not required because the resource editor attaches the appropriate application class to the beginning of each resource string prior to writing the string to the .Xdefaults file (or a selected app-defaults file) following an editing session.

The "Name" parameter is a descriptive explanation of each resource to be customized. This parameter defines the resource descriptors generated in the list 950 of resource descriptors in the scrollable window 940. Whereas the X Window resource string must be in English and follow the X Window resource specification format, the resource descriptor provided by the "Name" parameter can be in any language, thus making the graphical resource editor completely language independent.

The "Values" parameter is provided because some data types require additional data from which to create the custom interface window 300.

It will observed from FIG. 6 that the list of resource descriptors 950, the resource value display fields 960 and the resource value selection object 970 are positioned in successive horizontal groups in the scrollable window 940. Each horizontal group corresponds to a single editable resource that includes a resource descriptor, a resource value display field and a resource value selection object. Each horizontal group corresponds to a single line in the app-custom file. For example, the first horizontal group in the scrollable window panel 940 in FIG. 6 would correspond to the following app-custom file line:

"General" Color * bottomShadowColor "bottom shadow color"

Following are additional examples of app-custom file syntax:

The color, font, cursor, filename, number, and string data types all use the following syntax:

Group Type Resource Name;

Following is an example of a color resource app-custom file syntax:

"Menu Bar" Color *menubar*background "menu bar background";

A picture data type can be specified in the app-custom file using the following syntax:

Group Picture Resource Name PictureType;

where the items can be any strings. Following is an example of this app-custom file syntax:

Icon Picture *appIcon "application icon" bitmap;

The PictureType value can be one of three types: bitmap, pixmap, or all. I

f bitmap is set, only bitmaps can be browsed; pixmap is similar.

However, if all is set, both bitmaps and pixmaps are browsed.

Bitmaps are black and white images where filenames end with .xbm; pixmaps are multicolored images where file extensions are .px.

The selectmany data type allows many values to be selected from a list of choices. It is limited to 20 items. A selectmany data type can be specified in the app-custom file using the following syntax:

    ______________________________________
    Group SelectMany Resource     Name
          "Separator"
                     Item1 [= String]
                                  Item2 [= String] . . .;
    ______________________________________

    ______________________________________
    Foods    SelectMany  *iceCream  "Ice Cream Choices"
             " " vanilla chocolate strawberry  ;
    ______________________________________

    ______________________________________
    Foods    SelectMany  *iceCream  "Ice Cream Choices"
             vanilla = "Vanilla Flavor"
             chocolate = Fudge
             strawberry  ;
    ______________________________________

    ______________________________________
    Group   SelectOne  Resource  Name
            Item1 [= String] Item2 [= String]. . . ;
    ______________________________________

    ______________________________________
    Foods   SelectOne  IceCream  "Ice Cream Choices"
            vanilla chocolate strawberry  ;
    ______________________________________

    ______________________________________
    Foods    SelectOne  *iceCream   "Ice Cream Choices"
             vanilla = "Vanilla Flavor"
             chocolate = Fudge
             strawberry  ;
    ______________________________________

    ______________________________________
    ! XClock app-custom file
    Size   Number    *width     "width of clock";
    Size   Number    *height    "height of clock";
    Color  Color     *foreground
                                "foreground";
    Color  Color     *hands     "analog hands";
    Color  Color     *highlight "highlight analog hands";
    Color  SelectOne *reversevideo
                                "reverse video"
    true false;
    Font   Font      *font      "digital clock font";
    Behavior
           Number    *update    "interval of updates/n
                                (sec)";
    Behavior
           SelectOne *analog    "type of clock"
    true = analog false = digital;
    Behavior
           SelectOne *chime     "chime every half hour"
    true false;
    Behavior
           Number    *padding   "internal padding
                                (pixels)";
    ______________________________________

    ______________________________________
    !.Xdefaults file
    *background:       SkyBlue
    *foreground:       Red
    !CUSTOM BEGIN
    xclock.width       200
    xclock*foreground: medium goldenrod
    xclock*background: forest green
    !CUSTOM END
    ______________________________________

    ______________________________________
    resource = App*Form*button1.background
    resource segment = App
    resource last segment = background   last.sub.-- token =.
    remainder = *Form*button1
    ______________________________________

    ______________________________________
    */.sub.-- set.sub.-- and.sub.-- search recursive function */
    loop looking at all the children of each widget
    if the resource segment and current widget name or class match
    if `.` is the resource separator
    if the end of the resource string has been reached
    if `*` is the last separator then set the value over this
    widget and all its descendents else if `.` then set the
    value over this widget only
    else
    descend the widget tree, parse off the resource
    segment, determine the children of this widget and call
    .sub.-- set.sub.-- and.sub.-- search procedure for each child widget
    return
    (At this point, the .sub.-- set.sub.-- and.sub.-- search recursive
    function
    returns so that this widget's siblings will be evaluated).
    if `*` is the resource separator
    if the end of the resource string has been reached
    if `*` is the last separator then set the value over this
    widget and all its descendents else if `.` then set the
    value over this widget only
    else
    descend the widget tree, parse off the resource
    segment, determine the children of this widget and call
    .sub.-- set.sub.-- and.sub.-- search procedure for each child widget
    else
    if `.` is the resource separator
    continue looping - call .sub.-- set.sub.-- and.sub.-- search procedure
    to
    look at the rest of the siblings of this widget
    if `*` is the resource separator
    descend the widget tree but don't parse the resource
    string and continue looping call .sub.-- set.sub.-- and.sub.-- search
    procedure to look at the rest of the siblings
    end loop
    ______________________________________

• Inventors
  Swanson, Sara J.;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Feb-11-1997
• Current US Classes:
  345/781
  345/866
  717/111
  717/113
• Application #
  479262
• International Classes
  G06F 003/14
• Field of Search
  395/155 395/DIG.
• Examiner
  Kriess; Kevin A.
• Agent
  Baker, Maxham, Jester & Meador
• US Patent References:
  4648046
  5097411
  5115501
  5327529
  5369778