An item can be either a character string or a graphic representation (bitmap or pixmap).

A character string for items must be compatible with the menu font that is used. Character strings must be typed precisely using one of the following styles:

An item in either X bitmap (XBM) or X pixmap (XPM) file format can be created. Using the @ (at sign) in the menu syntax tells the window manager that what follows is the pathname for a bitmap or pixmap file:

@bitmapfile function [argument]

The following is an example of a newly created menu. The menu is named Graphics Projects. The menu items are all bitmaps symbolizing different graphics projects. The bitmaps are kept in the directory /users/pat/bits. When the user selects a symbol, the graphics program starts and opens the appropriate graphics file.

Another method for specifying the pathname is to replace /users/pat/ with the ~/ (tilde and slash) characters. The ~/ specifies the user's home directory. Another method is to use the bitmapDirectory resource. If the bitmapDirectory resource is set to /users/pat/bits, then a menu item could be specified as follows:

You can use mnemonics and keyboard accelerators in the menus that you create. Mnemonics are functional only when the menu is posted; accelerators are functional whether or not the menu is posted. A mnemonic specification has the following syntax:

mnemonic = _character

The _ (underbar) is placed under the first matching character in the label. If there is no matching character in the label, no mnemonic is registered with the window manager for that label. The accelerator specification is a key action with the same syntax as is used for binding keys to window manager functions:

key context function [argument]

When choosing accelerators, be careful not to use key actions that are already used in key bindings. (See Section 6.5 for information about keyboard bindings.)

The following line from the default Window Menu illustrates mnemonic and accelerator syntax:

Restore _R Alt<Key>F5 f.normalize

The predefined Motif Window Manager functions are listed in Table 6-1. Each mwm function operates in one or more of the following contexts:

Each function is activated by one or more of the following devices:

Any selection that uses an invalid context, an invalid function, or a function that does not apply to the current context is grayed out. For example, the Restore selection on a terminal window's Window Menu and the Minimize selection on an icon's menu are invalid. Also, menu items are grayed out if they are assigned the f.nop (no operation performed) function.

If you want your new menu to appear whenever a certain mouse button or keyboard key is pressed, follow these steps:

For example, you may want to create a root menu that gives some control over the entire screen area. The definition of a root menu might look as follows:

Once you have defined the menu, you need to bind the menu to a mouse button in your .mwmrc file:

<Btn3Down>  root f.menu RootMenu

The Motif Window Manager provides default button bindings. These button bindings define the functions of the window frame components. The user-specified button bindings that are defined with the buttonBindings resource are added to the built-in button bindings. The default value for this resource is DefaultButtonBindings (see Table 6-2).

The syntax for button bindings is as follows:

Buttons ButtonBindingSetName
{
button context [| context] function [argument]
button context [| context] function [argument]
...
button context [| context] function [argument]
}

Each line identifies a certain mouse button action, followed by the context in which the button action is valid, followed by the function to be done. Some functions require an argument.

To modify the default button bindings, you need to edit either system.mwmrc to make system-wide changes or .mwmrc to make changes to the local environment. The easiest way to modify button bindings is to change the default bindings or to insert extra lines in the DefaultButtonBindings.

When modifying or creating a button binding, you need to first decide which mouse button to use and which action is performed on the button. Make sure you do not use button-action combinations already used by Motif. You might want to require a simultaneous key press with the mouse button action. This is called modifying the button action. Modifiers increase the number of possible button bindings you can make (see Table 6-3).

---

Note: Binding a function to a mouse button-down event in a window, as would be done in the following example, has some undesirable side effects. <Btn1Down> window f.raise Once this binding is made, double clicking of that button on a PushButton inside a window will not be interpreted as a double-click, and the default PushButton action will not be taken. Therefore, when rebinding these events, it is important to keep the context of the rebinding as constrained as possible.

---

On some systems, you can bind up to five buttons if you have a 3-button mouse. For example, Button 4 is the simultaneous press of Buttons 1 and 2. Button 5 is the simultaneous press of Buttons 2 and 3. Each button can be bound with one of four actions (see Table 6-4).

After choosing the optional modifier and the mouse button action, you must decide under which context(s) the binding works (see Table 6-5).

The context indicates where the pointer must be for the button binding to be effective. For example, a context of window indicates that the pointer must be over a client window or window frame for the button binding to be effective. The frame context is for the window frame around a client window (including the border and title bar), the border context is for the border part of the window frame (not including the title bar), the title context is for the title bar of the window frame, and the app context is for the application window or client area (not including the window frame).

The following is an example of a button binding. Imagine you have created your own Graphics Projects menu and you want to display the menu with a button action. You choose Alt as a modifier and Btn3Down as the button action. You decide the pointer must be on the workspace. The function name for posting a special menu is f.menu and the argument is the menu name Graphics Projects. The following line in the DefaultButtonBindings in your .mwmrc file creates the button binding:

Alt<Btn3Down>        root    f.menu  "Graphics Projects"

If inserting a new button binding into the DefaultButtonBindings set is not enough, you may need to make a complete new set of button bindings. To create a new button binding set, use the DefaultButtonBindings in your .mwmrc file as a model. After you have created a new button binding set, use the buttonBindings resource to tell the window manager about it.

The buttonBindings resource specifies a button binding set. The default value of the resource is DefaultButtonBindings. Use the following syntax for specifying the resource in your .Xdefaults file:

Mwm*buttonBindings: NewButtonBindingSetName

This line directs the window manager to use NewButtonBindingSetName as the source of its button binding information. The button bindings are assumed to exist in the file named by the configFile resource; the default is .mwmrc.

For example, suppose that you want to specify a completely new button binding set instead of inserting a line in the existing DefaultButtonBindings set. The following entry in your .mwmrc file creates a new button binding set:

Buttons GraphicsButtonBindings
{
<Btn3Down>  root f.menu "Graphics Projects"
}

The following line in your .Xdefaults file references the new button binding set:

Mwm*buttonBindings: GraphicsButtonBindings

To display the graphics menu, press Button 3 on the mouse when the pointer is on the workspace.

Motif has default key bindings. These key bindings are replaced with user-specified key bindings specified with the keyBindings resource. Table 6-6 lists the default key binding specifications.

The syntax for keyboard bindings is as follows:

Keys KeyBindingSetName
{
key context [| context] function [argument]
key context [| context] function [argument]
...
key context [| context] function [argument]
}

Each line identifies a unique key press sequence, followed by the context in which that sequence is valid, followed by the function to be done. Some functions require an argument. Context refers to the location of the keyboard input focus when a key is pressed.

To modify the default keyboard bindings, you need to edit either system.mwmrc to make system-wide changes or .mwmrc to make changes to the local environment. The easiest way to modify keyboard bindings is to change the default bindings or to insert extra lines in the DefaultKeyBindings.

When modifying a keyboard binding, you need to decide which key you want to bind and which action the key performs. Then choose the context in which the key binding is to work (see Table 6-7).

Note that if f.post_wmenu or f.menu is bound to a key, mwm automatically uses the same key for removing the menu from the screen after it has been popped up.

Suppose you wanted to eliminate a particular keyboard binding. To disable it, you can delete or comment out the appropriate line in your .mwmrc file. You comment out a line by placing an ! (exclamation point) comment character at the beginning of the line. The following shows an example of a commented-out line in a .mwmrc file:

Keys  DefaultKeyBindings
{
!Shift<Key>Escape    icon|window     f.post_wmenu
Alt<Key>Tab      window          f.next_key
}

With keyboard bindings, as with button bindings, you have the option of creating a whole new binding set. To do so, use the DefaultKeyBindings of your .mwmrc file as a model. After you have created the new keyboard binding set, use the keyBindings resource to specify a key binding set in your .Xdefaults file:

mwm*keyBindings: NewKeyboardBindingSetName

The default value for this resource is DefaultKeyBindings.

Add the following to your .mwmrc file to use virtual panning.

Ensure that the name of your button bindings match the name given for the resource value Mwm*buttonBindings in your .Xdefaults file.

Buttons MyButtonBindings
{
    <Btn2Down>          root                    f.menu GotoMenu
    Meta<Btn1Down>      root                    f.track_pan
}

Ensure that the name of your key bindings match the name given for the resource value Mwm*keyBindings in your .Xdefaults file.

Keys MyKeyBindings
{
    Meta<Key>Up        window|root   f.pan 0,-100
    Meta<Key>Down      window|root   f.pan 0,100
    Meta<Key>Left      window|root   f.pan -100,0
    Meta<Key>Right     window|root   f.pan 100,0
}

To set up a menu that lets you quickly switch to different locations on the virtual desktop, code it as follows. You can then restart your mwm application.

Menu GotoMenu
{
    Up-Left     f.goto 1500,1100
    Up          f.goto 0,1100
    Up-Right    f.goto -1500,1100
    Left        f.goto 1500,0
    Home        f.goto 0,0
    Right       f.goto -1500,0
    Down-Left   f.goto 1500,-1100
    Down        f.goto 0,-1100
    Down-Right  f.goto -1500,-1100
}

You can add the following to your .Xdefaults file to keep mwm from moving all your windows back to the visible part of the screen at startup:

Mwm*positionOnScreen:  False

Note that it is important to set the positionOnScreen resource to False because mwm automatically repositions all off-screen windows back to the display screen on restart.

To set up a menu to go to preset positions on the virtual canvas, add the following:

Mwm*GotoMenu*numColumns:    3
Mwm*GotoMenu*packing:        PACK_COLUMN
Mwm*GotoMenu*orientation:    HORIZONTAL
Mwm*GotoMenu*alignment:      ALIGNMENT_CENTER

To ensure consistency with the .mwmrc file, you can add the following lines:

Mwm*buttonBindings:     MyButtonBindings
Mwm*keyBindings:        MyKeyBindings

To prevent the client and icon windows from moving, you can use the following lines:

Mwm*wsm.iconPinned:     True
Mwm*wsm.clientPinned:   True
Mwm*iconPinned:         True

Where wsm is the workspace manager, which controls aspects of the desktop beyond the confines of the windows actually visible on the screen.