AXE is an application framework which encapsulates much of the functionality in X-Windows. The classes in AXE encapsulate the usual resources in X, like windows, graphic contexts, cursors and fonts. Creating objects of these classes also creates the corresponding resources on the X workstation. These objects and their X resources are controlled though member functions of the classes. Other classes add represent user interface concepts, like menu's dialog panels, button and scrollbars. Using the classes in AXE, it is easy to create application programs that use a graphical user interface.
The core of an AXE-application is a xapplication -derived object. There is a single object derived from xapplication in each application program. This object takes takes of initialization, event dispatching and cleanup. Unlike traditional C programs, a program written with AXE does not need to have a main() function. AXE has its own main() which calls the member functions of the application's xapplication-derived object.
Everything visible on the screen and all user interaction is done by window objects. Windows are used for drawing graphics and capturing input from the mouse and keyboard. Some windows can send commands back to the xapplication object, e.g. when a menu item or a button is clicked.
Windows are organized in a tree-structured hierarchy. At the top of the hierarchy is the root window. The root window is created by the X server and cover the whole screen. All application's windows are children of the root window. An application creates one or more top-level windows, which may themselves contain many children or subwindows. The top-level windows of an application are direct children of the root window and are usually managed by the window manager. These top-level windows of the applications are of the managed_window class. The xapplication-derived object maintains a hashtable of all windows that are created by the application.
A program written with AXE is driven by three communication mechanisms:
Events originate from the X server and are sent to a window as a result of input from the mouse or keyboard.
Commands are notifications from certain windows and are sent to either the top-level window which currently has the focus or to the application itself.
Messages are sent from child windows to their parent window.
The figure below shows how these three communication mechanisms are related:
Constructing menus involves two class hierarchies, both of which are derived from the window class. The interaction of menus is implemented in menu_item objects. A menu_item is a selectable object that can either send a command to the application or show a submenu. Collections of menu items are contained in a menu_container objects, like a menu_bar or a popup_menu. Both container have equivalent auto-sizing behaviour but a menu_bar is a long-stretched window on the edge of a parent window and a popup_menu is a direct child of the root window. The similarity lies in the fact that both the menu_bar and the popup_menu rearrange their child windows (usually menu items) to make them fit nicely in the container window.
A menu_bar is a window that sits at the edge of it parent window and acts as a container for other windows. It puts all its child windows next to each other and makes itself fit exactly in its parent window. The size of a menu_bar is dictated by the parent window on one side and the child windows on the other side.
Menu bars come in two flavors: horizontal and vertical. A horizontal menu bar has a larger width than height. A vertical menu bar has a large height and a relatively smaller width. Depending on the flavor of the menu bar it will span its parent window horizontally or vertically. A horizontal menu bar matches its width with the parent window; a vertical menu bar changes its height to fit in its parent window.
A menu bar rearranges its child windows so they appear next to eachother. Child windows are spread left to right in a horizontal menu bar and top to bottom in a vertical menu bar.
In the direction that does not span the parent of the menu bar, all sizes of the menu bar's children and the menu bar itself are set to the same value. So the menu bar spans its parent in one direction and the menu bar's children span the menu bar in the other direction. In that direction the size of the menu bar and its child windows is determined by the largest child window.
A menu bar may be user-dockable, i.e. click and drag in the background of the menu_bar can move the menu bar to an other edge of its parent window.
A popup_menu is another container for menu_item objects. It is an unmanaged child of the root window and is made visible as a result of the selection of another menu item. A popup_menu rearranges its child windows similarly to a menu_bar but its size does not depend on a parent window.
A dialog is a managed_window used for obtaining input from the user. A dialog contains various user interface objects like buttons, edits, static texts and scrollbars
Below is an alphabethical list of all classes in AXE. The Class Diagram shows how these classes are related.
The xapplication or display object may contain 'standard' GC's which can be used by all windows.
Graphic output happens in a device context which is a combination of a drawable and a GC, but can also relate to another output device, like printers, plotters or meta-files.