Graphical User Interface Having a Shared Menu Bar for Opened Applications

The present application contains subject matters related to co-pending application Ser. No. 08/587,182, entitled METHOD AND SYSTEM FOR MERGING MULTIPLE WINDOWS EVENT DISTRIBUTION, filed on even date herewith and assigned to the assignee hereof and incorporated by reference herein.

1. Technical Field

The present invention relates in general to a data processing system having a graphical user interface and, more specifically, to a data processing system with GUI where multiple software objects share a common menu.

2. Description of the Related Art

Computer systems using graphical user interfaces are well-known in the art. Within a typical graphical user interface, more than one application can be opened with the focus to a particular application being shifted from one to another as desired by the user. Each time an application is opened, the typical application has its own menu bar above the window. Some operating systems have attempted to standardize menu items across applications. One such operating system is the Macintosh operating system developed by Apple Computers. Further, OpenDoc is a software system originally implemented on the Macintosh operating system. The MacOS includes a menu manager component that allows applications to create private menu bars, populate the menu bars with menus, and then display the menu bars in a shared location, typically outside the application window at the top of the screen. When the user switches from one application to another, the shared menu bar automatically displays the new applications menus.

OpenDoc is being implemented across various platforms of operating systems, such as, for example, the Unix-based operating system developed by IBM Corporation known as AIX, which uses the X-Windows graphics system. Within the cross-platform Unix-based system is a GUI toolkit known as Motif. The Motif toolkit does not provide a menu manager or shared menu bar. The Motif applications create one Motif menu bar at the top of the main application window. This menu bar is created with all the menu items needed by that application and it is not altered during the execution of the application. The changing menu bar is not necessary in this environment since only one application is using the menu bar.

Since the OpenDoc compound object paradigm allows several OpenDoc objects, also known as software components, to share the same window, the menu bar must also be shared between these objects. Each OpenDoc object must be able to specify its own set of menu items. The OpenDoc shared menu bar must be modified each time the focus is switched to a different OpenDoc part handler.

Another problem regarding OpenDoc menu bars is that they are supposed to produce special "menu effects" that are not standard Xlib user events. Standard Motif menu selections result in callback functions being invoked for the individual menu push button on which the user clicks.

It is therefore one object of the present invention to provide a data processing system having a graphical user interface.

It is another object of the present invention to provide a data processing system with GUI where multiple software objects share a common menu.

The foregoing objects are achieved as is now described. According to the present invention, a computer system and method of operation are disclosed that manages a menu bar shared by a group of active applications. The computer system typically uses a bus coupled to a central processing unit and further coupled via the bus to a computer system memory. The computer system further includes an X Window menu manager and an X Window menu bar, both of which are located within the computer system memory during operation. The X Window menu manager includes a shared menu library. The X Window menu manager implements simultaneously instantiation of a set of menu widgets from the shared menu library that are associated with a computer program selected from the several active computer programs when the program focus is shifted to one of the active programs. The X Window menu bar, which is controlled by the X Window menu manager and displayable by the computer system, is shared by the plurality of active programs so that only the computer program receiving the application focus has its associated set of menu widgets displayed after the focus shift. The method for providing the shared menu bar is accomplished as follows. Initially, the system establishes a part editor for each active application. Next, the system passes the focus to one of the active applications and then retrieves a copy of a base menu bar from a window state object in the X Window environment. Afterwards, the system selects the appropriate widgets for display on the computer system. Next, the base menu bar is displayed and then the part editor is notified of the selected widgets to be displayed in the shared menu bar. Lastly, the system displays the selected widgets in the base menu bar or X Window menu bar.

In the preferred embodiment, the X Window or base menu bar is a Motif menu bar and the selected widgets are selected from a OpenDoc menu library. Additionally, the Motif menu bar further comprises a Motif widget library.

Further to the preferred embodiment, an OpenDoc system is operated in the X Window environment and includes an OpenDoc menu library that communicates with the part editor for each active application. The menu library further communicates with the Motif widget library, which in turn communicates with an Xt toolkit library. The Xt toolkit library communicates with an Xlib graphics library that provides the screen drawing calculations for the display in the computer system.

Another embodiment of the computer system is one that operates in an X Window graphical user interface environment again with a plurality of active computer programs. A common menu bar that is displayable by the computer system and shared by the plurality of active computer programs is provided. The common menu bar includes a shared X Window menu library having a set of widgets associated with each of the active computer programs and an X Window menu manager connected to the shared menu library that displays in the common menu bar a set of widgets associated with one of the active computer programs. The system focus is shifted to this selected active computer program and the menu manager and menu library provide the appropriate widgets for the common menu bar to represent the widgets accessible to the user in the common menu bar.

The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts a preferred embodiment of a data processing system which may be utilized to implement the method of the present invention.

FIG. 2 is a block diagram of the principal components of system unit of data processing system.

FIG. 3 depicts a GUI, where application A and application B are shown.

FIG. 4 is a block diagram of the part editor for each application and the AIX OpenDoc menu library according to the present invention.

FIG. 5 depicts a flow diagram of the setting up of a shared menu bar on OpenDoc for AIX according to the present invention.

With reference now to the figures and in particular with reference to FIG. 1, there is illustrated a preferred embodiment of a data processing system which may be utilized to implement the method of the present invention. As illustrated, data processing system 10 includes system unit 12, display device 14, keyboard 16, mouse 18, and printer 20. As is well-known in the art, system unit 12 receives data for processing from input devices such as keyboard 16, mouse 18, or local area networking interfaces (not illustrated). Mouse 18 is preferably utilized in conjunction with a graphical user interface (GUI) in which hardware and software system objects, including data processing system components and application programs, are controlled through the selection and manipulation of associated graphical objects displayed within display device 14. Although data processing system 10 is illustrated with mouse 18, those skilled in the art will recognize that other graphical pointing devices, including a graphics tablet, stylus, light pen, joystick, puck, trackball, trackpad, and the IBM TrackPoint.TM. can also be utilized. Data processing system 10 presents output data to a user via display device 14 and printer 20. To support storage and retrieval of data, system unit 12 further includes diskette drive 22, hard disk drive 23, and CD-ROM drive 24, which are connected to system unit 12 in a well-known manner. Of course, those skilled in the art are aware that other conventional components can also be connected to system unit 12.

Referring now to FIG. 2, there is depicted a block diagram of the principal components of system unit 12 of data processing system 10. As illustrated, system unit 12 includes a central processing unit (CPU) 26 which executes software instructions. While any appropriate microprocessor can be utilized for CPU 26, CPU 26 is preferably one of the PowerPC.TM. line of microprocessors available from IBM Microelectronics. Alternatively, CPU 26 can be implemented as one of the 80X86 microprocessors, which are available from a number of vendors. In addition to CPU 26, an optional math coprocessor 27, cache controller 28, and cache memory 30 are coupled to high-speed CPU local bus 25. Math coprocessor 27 is an optional processor, distinct from CPU 26, that performs mathematic computations with greater efficiency than CPU 26. Math coprocessor 27 is optional since the performance advantage provided by a math coprocessor may be achieved by enhancements to CPU 26, such as the implementation of multiple floating-point execution units. Cache memory 30 comprises a small high-speed memory which stores frequently accessed data and instructions. The operation of cache 30 is controlled by cache controller 28, which maintains a directory of the contents of cache 30 and enforces a selected cache coherency protocol.

CPU local bus 25 is coupled to buffer 32 to provide communication between CPU local bus 25 and system bus 34, which extends between buffer 32 and a further buffer 36. System bus 34 is connected to bus control and timing unit 38 and direct memory access (DMA) unit 40, comprising central arbiter 48 and DMA controller 41. DMA controller 41 supports memory accesses that do not involve CPU 26. Direct memory accesses are typically employed to transfer data directly between RAM 58 and an "intelligent" peripheral device, such as disk adapter 82. DMA requests from multiple peripheral devices are arbitrated by central arbiter 48. As described below, central arbiter 48 also regulates access to devices coupled to expansion bus 44 by control signals transmitted via arbitration control bus 42.

CPU 26 accesses data and instructions from and stores data to volatile random access memory (RAM) 58 through memory controller 50, which comprises memory control unit 50, address multiplexer 54, and data buffer 56. Memory control unit 52 generates read enable and write enable signals to facilitate storage and retrieval of data and includes address translation facilities that map virtual addresses utilized by CPU 26 into physical addresses within RAM 58. As will be appreciated by those skilled in the art, RAM 58 comprises a number of individual volatile memory modules which store segments of operating system and application software while power is supplied to data processing system 10. The software segments are partitioned into one or more virtual memory pages which each contain a uniform number of virtual memory addresses. When the execution of software requires more pages of virtual memory that can be stored within RAM 58, pages that are not currently needed are swapped with the required pages, which are stored within nonvolatile storage devices 22-24.

Memory controller 50 further includes address multiplexer 54, which selects particular addresses within RAM 58, and data buffer 56, which buffers data read from and stored to RAM 58. Memory controller 50 also provides memory protection that isolates system processes and user processes within the virtual address space allocated to each process. Thus, a program running in user mode can access only memory allocated to its virtual address space; the user mode program cannot access memory within another process's virtual address space unless memory sharing between the processes is supported and the program has the appropriate privileges for the access.

Still referring to FIG. 2, buffer 36 provides an interface between system bus 34 and expansion bus 44. Connected to expansion bus 44 are a number of I/O slots 46 for receiving adapter cards which may be further connected to an I/O device or memory. Arbitration control bus 42 couples DMA controller 41 and central arbiter 48 to I/O slots 46 and disk adapter 82. By implementing a bus arbitration protocol, central arbiter 48 regulates access to expansion bus 44 by extension cards, controllers, and CPU 26. In addition, central arbiter 48 arbitrates for ownership of expansion bus 44 masters coupled to expansion bus 44. Bus master support allows multiprocessor configurations of expansion bus 44 to be created by the addition of bus master adapters containing a processor and its support chips. System bus 34 is coupled to planar I/O bus 68 through buffer 66. Attached to planar I/O bus 68 are a variety of I/O adapters and other peripheral components, including display adapter 70, disk adapter 82, nonvolatile RAM 74, clock 72, serial adapter 78, timers 80, read only memory (ROM) 86, CD-ROM adapter 88, keyboard/mouse controller 84, network adapter 85, modem 87, and parallel adapter 76. Display adapter 70 translates graphics data from CPU 26 into R, G, and B video signals utilized to drive display device 14. Depending upon the operating system and application software running, the visual output may include text, graphics, animation, and multimedia video. Disk adapter 82 controls the storage of data to and the retrieval of data from hard disk drive 24 and diskette drive 22. Disk adapter 82 handles tasks such as positioning the read/write heads within drives 22 and 23 and mediating between drives 22 and 23 and CPU 26. Nonvolatile RAM 74 stores system configuration data that describes the present configuration of data processing system 10. For example, nonvolatile RAM 74 contains information that describes the capacity of hard disk drive 24 or a diskette placed within diskette drive 22, the type of display device 14, the amount of free RAM 58, and the present system configuration. These data remain stored in nonvolatile RAM 74 when power is removed from data processing system 10.

Clock 72 is utilized by application programs executed by CPU 26 for time of day calculations. Serial adapter 78 provides a synchronous or asynchronous serial interface which enables data processing system 10 to communicate with a remote data processing system or peripheral device. Serial communication is governed by a serial communication protocol such as RS-232, RS-422, or the like. Timers 80 comprise multiple interval timers which may be utilized by application or operating system software to time one or more selected events within data processing system 10.

ROM 86 typically stores a basic input/output system (BIOS) which provides user-transparent I/O when CPU 26 is operating under the DOS operating system. BIOS also includes power on self-test (POST) diagnostic routines which perform system set up at power on. For example, POST interrogates hardware, allocates a BIOS data area (BDA), constructs an interrupt vector table to point to interrupt handling routines within ROM 86, and initializes timers 80, clock 72 and other devices within system unit 12. CD-ROM adapter 88 interfaces CD-ROM drive 24 with planar I/O bus 34 to support retrieval of data from an optical disk loaded within CD-ROM drive 24. Keyboard/mouse controller 84 interfaces system unit 12 with keyboard 16 and a graphical pointing device such as mouse 18. As will be described in greater detail below, keyboard/mouse controller 84 receives a serial signal from mouse 18 that indicates each incremental displacement of mouse

Finally, system unit 12 includes network adapter 85, modem 87, and parallel adapter 76, which facilitate communication between data processing system 10 and peripheral devices or other data processing systems. Network adapter 85 is utilized to connect data processing system 10 to an unillustrated local area network (LAN). A LAN provides a user of data processing system 10 with a means of electronically communicating information, including software, with a remote computer or a network logical storage device. Additionally, LAN supports distributed processing, which enables data processing system 10 to share a task with other data processing systems linked to the LAN. Modem 87 supports communication between data processing system 10 and another data processing system over a standard telephone line. For example, modem 87 may be utilized to connect data processing system 10 to an on-line information service, such as the information service provided by Prodigy Services Corporation under the service mark "PRODIGY." Such on-line service providers frequently offer software that can be downloaded into data processing system 10 via modem 87. Furthermore, through modem 87, data processing system 10 can access other sources of software, such as a server, an electronic bulletin board, and the Internet or World Wide Web. Parallel port 76 transmits printer control signals and output data to printer 20 through a parallel port.

As is typical of many data processing systems, following power on, the various hardware components of data processing system 10 will each execute its own internal reset procedures to regain a stable, known state. At the completion of these reset procedures, CPU 26 will execute POST code within ROM 86 to initialize system hardware, setup the BIOS data area, and construct and interrupt vector table, as well as other tasks. Following POST, a "boot strap" or primary operating system loader is run to load segments of an operating system (OS) 100 (see FIG. 3) into RAM 58 and launch execution of OS 100, which in a preferred embodiment of the present invention utilizes AIX, available from IBM Corporation. For an overview of the present invention, the following is given. The operating system provided for the Macintosh family of computers, manufactured by Apple Corporation, includes a menu manager that allows applications to create private menu bars, populate that with menus, and display them in a shared location, typically at the top of the screen. When a user switches from one application to another, the shared menu bar automatically displays the new applications' menus. In contrast, AIX does not provide a menu bar or a common location for menu bar display. Instead, each application window is responsible for creating and displaying its own menu bar, within its own window.

Most AIX applications use the Motif toolkit to implement their menu bars. The Motif toolkit is a well-known standard for use in the AIX body of applications and is well-known to those skilled in the art. It is desirable for OpenDoc menus to share the Motif "look and feel;" however, Motif alone is not adequate for implementing OpenDocs menu APIs. In particular, OpenDoc allows users to create PlatformMenu objects independently of an OpenDocMenuBar object. Under Motif, the Motif menu shell widgets must always be created as a child of an existing menu bar widget and can never be moved to a different menu bar.

An example of such is shown in FIG. 3. In FIG. 3 is shown a GUI 202, where application A and application B are shown. Application A 204 includes a menu bar 206 while application B 208 includes a menu bar 210. Motif API calls and Motif callbacks are exchanged between application A and the Motif widget library 212 which further exchanges API calls and callbacks between XT toolkit library 214. The toolkit library 214 exchanges X API calls and XEvents with the Xlib graphics library 216, which provides screen display in the GUI 202. The same operation occurs for application B 208, which operates independently of the application A 204.

The present invention proposes a special shared AIX OpenDoc menu library to act as a menu manager. The OpenDoc menu library switches the visible menu bar to match the OpenDoc object in focus. An ODPlatformMenu object is defined that handles the creation of individual Motif menu bars. OpenDoc part handlers, former applications converted into OpenDoc objects, never directly create Motif menu widgets. Instead, they pass the necessary information to the ODPlatformMenu and ODMenuBar objects, which then create and manage the Motif widgets as necessary.

This implementation allows for "just in time" instantiation of the Motif widgets. This means that the widgets are not created until right before they are displayed. This contrasts with typical Motif applications that create all the menu widgets at program initialization. The ODPlatformMenu object also takes care of registering "dummy" callbacks for all menu items and converting these into synthetic OpenDoc "menu events."

An example of the AIX OpenDoc menu library is illustrated in FIG. 4, which is a block diagram of the part editor for each application and the AIX OpenDoc menu library 302. A Part editor 304 is provided for each application. Each Part editor 304 passes OpenDoc API calls to OpenDoc menu library 302 and receives OpenDoc menu events from the same.

The OpenDoc menu library 302 then receives Motif callbacks from and sends Motif API calls to Motif widget library 212. Motif widget library 212 receives Xt callbacks from and sends Xt API calls to Xt toolkit library 214. Xt toolkit library 214 also receives XEvents from and sends X API calls to the Xlib graphics library 216. The graphics library 216 sends and receives these calls and events from and to GUI 200. Shown in GUI 200 is a single window 310 where software component A 312 and software component B 314, represented by part A and part B, respectively, are illustrated that both share a common OpenDoc shared or base menu bar 316.

The setting up of a parts menu bar on OpenDoc for AIX is depicted in the flow diagram of FIG. 5. First, in block 510, the part retrieves a copy of the base menu bar from the window state object. Next, in block 512, the part generates a new PlatformMenu using the menu bar's NewMenu() method. In block 514, the part adds choices to the platform menu using its AddChoiceLast() method. Then, in block 516, the part uses the menu bar's AddMenuBefore() method to emplace the new PlatformMenu(). In block 518, the part then calls the menu bar's Display() method. At this point the menu bar is now displayed and the part will be notified of the user's menu choices via the parts HandleEvent() method. A code implementation example is shown in the Appendix I, which further includes the private structure as used by PlatformMenu class. The code is given in SOM (C++) under OpenDoc.

Furthermore, changes to menu bar for PlatformMenu class and Motif widget support is also provided as listed in Appendix II. Whenever the DocShell gets a mouse or keyboard event, the DocShell then calls the MenuBar::HandleEvent(), which then checks to see if the mouse events window belongs to a widget in menu bar's hierarchy, or if the keyboard event matches an accelerator for one of the widgets in menu bar's hierarchy or one of the other menu keys described in the Motif style guide. Further, the third mouse button when activated will cause the active parts menu to pop up, regardless of the window under the pointer.

If the event does not belong to the menu bar, MenuBar::HandleEvent() will return false.

If the event does belong to the menu bar, it will be passed to XtDispatchEvent(), which then passes control to the OSF/Motif menu widget code until the user ends the menu interaction by releasing the button or pressing an appropriate key. If the user selects a menu item, a generic callback then notifies either the DocShell via a special HandleBaseMenultem() method or the active part, via the parts general HandleEvent() method.

As described above, aspects of the present invention pertain to specific "method steps" implementable on computer systems. In an alternate embodiment, the invention may be implemented as a computer program product for use with a computer system. Those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms, which include, but are not limited to: (a) information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM 86 or optical disks readable by CD-ROM drive 24); (b) information alterably stored on writable storage media (e.g., floppy disks within diskette drive 22 or hard disk drive 24); or (c) information conveyed to a computer through communication media, such as through a computer or telephone network. It should be understood, therefore, that such media, when carrying computer readable instructions that direct the method functions of the present invention, represent alternate embodiments of the present invention.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.