Index of Section 1 Manual Pages
| Interix / SUA | fvwm2.1 | Interix / SUA |
FVWM2(1) FVWM2(1)
NAME
fvwm2 - F(?) Virtual Window Manager (version 2) for X11
SYNOPSIS
fvwm2 [-blackout] [-clientId id] [-cmd config_command] [-d
displayname] [-debug] [-debug_stack_ring] [-f config_file]
[-h] [-replace] [-restore state_file] [-s] [-version]
[-visual visual_class] [-visualId id]
DESCRIPTION
Fvwm is a window manager for X11. It is designed to mini-
mize memory consumption, provide a 3D look to window
frames, and a virtual desktop.
Note that there are several window managers around that
have "fvwm" in their name. In the past, version 2.x of
fvwm was commonly called fvwm2 to distinguish it from the
former version 1.x (fvwm or even fvwm1). Since version
1.x has been replaced by version 2.x a long time ago we
simply call version 2.x and all versions to come, fvwm,
throughout this document, although the executable program
is named fvwm2. There is an fvwm offspring called fvwm95.
Although it is very similar to older versions of fvwm ver-
sion 2 it is technically a different window manager that
has been developed by different people. The main goal of
fvwm95 was to supply a Windows 95 like look and feel.
Since then fvwm has been greatly enhanced and only very
few features of fvwm95 can not be imitated by fvwm. No
active development has been going on for fvwm95 for sev-
eral years now. Unfortunately Red Hat (a popular Linux
distributor) has a pre-configured fvwm package based on
fvwm version 2.x that is called fvwm95 too.
Fvwm provides both a large virtual desktop and multiple
disjoint desktops which can be used separately or
together. The virtual desktop allows you to pretend that
your video screen is really quite large, and you can
scroll around within the desktop. The multiple disjoint
desktops allow you to pretend that you really have several
screens to work at, but each screen is completely unre-
lated to the others.
Fvwm provides keyboard accelerators which allow you to
perform most window-manager functions, including moving
and resizing windows, and operating the menus, using key-
board shortcuts.
Fvwm has also blurred the distinction between configura-
tion commands and built-in commands that most window-man-
agers make. Configuration commands typically set fonts,
colors, menu contents, key and mouse function bindings,
while built-in commands typically do things like raise and
lower windows. Fvwm makes no such distinction, and
allows, to the extent that is practical, anything to be
changed at any time.
Other noteworthy differences between Fvwm and other X11
window managers are the introduction of the SloppyFocus
and NeverFocus focus methods. Focus policy can be speci-
fied for individual windows. Windows using SloppyFocus
acquire focus when the pointer moves into them and retain
focus until some other window acquires it. Such windows
do not lose focus when the pointer moves into the root
window. The NeverFocus policy is provided for use with
windows into which one never types (e.g. xclock, oclock,
xbiff, xeyes, tuxeyes) - for example, if a SloppyFocus
terminal window has focus, moving the cursor over a Never-
Focus decoration window won't deprive the terminal of
focus.
OPTIONS
These are the command line options that are recognized by
fvwm:
-blackout
This option is provided for backward compatibility
only. Blacking out the screen during startup is
not necessary anymore.
-clientId id
This option is used when fvwm is started by a ses-
sion manager. Should not be used by a user.
-cmd config_command
Causes fvwm to use config_command instead of 'Read
.fvwm2rc' as its initialization command. (Note
that up to 10 -f and -cmd parameters can be given,
and they are executed in the order specified.)
-d displayname
Manage the display called displayname instead of
the name obtained from the environment variable
$DISPLAY.
-debug Puts X transactions in synchronous mode, which dra-
matically slows things down, but guarantees that
fvwm's internal error messages are correct. Also
causes fvwm to output debug messages while running.
-debug_stack_ring
Enables stack ring debugging. This option is only
intended for internal debugging and should only be
used by developers.
-f config_file
Causes fvwm to read config_file instead of .fvwm2rc
as its initialization file. This is equivalent to
-cmd 'Read config_file'.
-h A short usage description is printed.
-replace
Try to take over from a previously running wm.
This does not work unless the other wm is ICCCM 2.0
compliant.
-restore state_file
This option is used when fvwm is started by a ses-
sion manager. Should not be used by a user.
-s On a multi-screen display, run fvwm only on the
screen named in the $DISPLAY environment variable
or provided through the -d option. Normally, fvwm
attempts to start up on all screens of a multi-
screen display.
-version
Prints the version of fvwm to stderr. Also prints
an information about the compiled in support for
readline, rplay, stroke, xpm, gnome hints, session
management and multibyte characters.
-visual visual_class
Causes fvwm to use visual_class for the window bor-
ders and menus. visual_class can be "StaticGray",
"GrayScale", "StaticColor", "PseudoColor", "True-
Color" or "DirectColor".
-visualId id
Causes fvwm to use id as the visualId for the win-
dow borders and menus. id can be specified as N
for decimal or 0xN for hexadecimal. See man page of
xdpyinfo for a list of supported visuals.
ANATOMY OF A WINDOW
Fvwm puts a decorative border around most windows. This
border consists of a bar on each side and a small L-shaped
section on each corner. There is an additional top bar
called the title-bar which is used to display the name of
the window. In addition, there are up to 10 title-bar
buttons. The top, side, and bottom bars are collectively
known as the side-bars. The corner pieces are called the
frame.
Unless the standard defaults files are modified, pressing
mouse button 1 in the title or side-bars begins a move
operation on the window. Pressing button 1 in the corner
frame pieces begins a resize operation. Pressing button 2
anywhere in the border brings up an extensive list of win-
dow operations.
Up to ten title-bar buttons may exist. Their use is com-
pletely user definable. The default configuration has a
title-bar button on each side of the title-bar. The one
on the left is used to bring up a list of window options,
regardless of which mouse button is used. The one on the
right is used to iconify the window. The number of title-
bar buttons used depends on which ones have mouse actions
bound to them. See the section on the Mouse command
below.
THE VIRTUAL DESKTOP
Fvwm provides multiple virtual desktops for users who wish
to use them. The screen is a viewport onto a desktop
which may be larger than the screen. Several distinct
desktops can be accessed (concept: one desktop for each
project, or one desktop for each application, when view
applications are distinct). Since each desktop can be
larger than the physical screen, divided into m by n pages
which are each the size of the physical screen, windows
which are larger than the screen or large groups of
related windows can easily be viewed.
The (m by n) size (i.e. number of pages) of the virtual
desktops can be changed any time, by using the DeskTopSize
built-in command. All virtual desktops must be (are) the
same size. The total number of distinct desktops does not
need to be specified, but is limited to approximately 4
billion total. All windows on a range of desktops can be
viewed in the FvwmPager, a miniature view of the desktops.
The pager is an accessory program, called a module, which
is not essential for the window manager to operate. Win-
dows may also be listed, along with their geometries, in a
window list, accessible as a pop-up menu, or as a separate
window, called the FvwmWinList (another module).
Fvwm keeps the windows on the desktop in a layered stack-
ing order; a window in a lower layer never obscures a win-
dow in a higher layer. The layer of a window can be
changed by using the Layer command. The concept of layers
is a generalization of the StaysOnTop flag of older fvwm
versions. The StaysOnTop and StaysPut Style options are
now implemented by putting the windows in suitable layers
and the previously missing StaysOnBottom Style option has
been added.
Sticky windows are windows which transcend the virtual
desktop by "Sticking to the screen's glass". They always
stay put on the screen. This is convenient for things like
clocks and xbiff's, so you only need to run one such gad-
get and it always stays with you. Icons can also be made
to stick to the glass, if desired.
Window geometries are specified relative to the current
viewport. That is:
xterm -geometry +0+0
creates a window in the upper-left hand corner of the vis-
ible portion of the screen. It is permissible to specify
geometries which place windows on the virtual desktop, but
off the screen. For example, if the visible screen is
1000 by 1000 pixels, and the desktop size is 3x3, and the
current viewport is at the upper left hand corner of the
desktop, invoking:
xterm -geometry +1000+1000
places a window just off of the lower right hand corner of
the screen. It can be found by moving the mouse to the
lower right hand corner of the screen and waiting for it
to scroll into view. A geometry specified as something
like:
xterm -geometry -5-5
places the window's lower right hand corner 5 pixels from
the lower right corner of the visible portion of the
screen. Not all applications support window geometries
with negative offsets. Some applications place the win-
dow's upper right hand corner 5 pixels above and to the
left of the upper left hand corner of the screen; others
may do just plain bizarre things.
There are several ways to cause a window to map onto a
desktop or page other than the currently active one. The
geometry technique mentioned above (specifying x,y coordi-
nates larger than the physical screen size), however, suf-
fers from the limitation of being interpreted relative to
the current viewport: the window may not consistently
appear on a specific page, unless you always invoke the
application from the same page.
A better way to place windows on a different page, screen
or desk from the currently mapped viewport is to use the
StartsOnPageorStartsOnScreen style specification (the suc-
cessors to the older StartsOnDesk style) in the .fvwm2rc
configuration file. The placement is consistent: it does
not depend on your current location on the virtual desk-
top.
Some applications that understand standard Xt command line
arguments and X resources, like xterm and xfontsel, allow
the user to specify the start-up desk or page on the com-
mand line:
xterm -xrm "*Desk:1"
starts an xterm on desk number 1;
xterm -xrm "*Page:3 2 1"
starts an xterm two pages to the right and one down from
the upper left hand page of desk number 3. Not all appli-
cations understand the use of these options, however. You
could achieve the same results with the following lines in
your .Xdefaults file:
XTerm*Desk: 1
or
XTerm*Page: 3 2 1
USE ON MULTI-SCREEN DISPLAYS
If the -s command line argument is not given, fvwm auto-
matically starts up on every screen on the specified dis-
play. After fvwm starts each screen is treated indepen-
dently. Restarts of fvwm need to be performed separately
on each screen. The use of
EdgeScroll 0 0
is strongly recommended for multi-screen displays. You
may need to quit on each screen to quit from the X session
completely. This is not to be confused with Xinerama sup-
port.
XINERAMA SUPPORT
Fvwm supports the Xinerama extension of newer X servers
which is similar to multi head support (multiple screens)
but allows to move windows between screens. If Xinerama
support has been compiled into fvwm, it is used whenever
fvwm runs on an X server that supports and uses multiple
screens via Xinerama. Without this option, the whole
desktop is treated as one big screen. For example, menus
might pop up right between two screens. The EdgeResis-
tance command allows to specify an explicit resistance
value for moving windows over the screen edge between two
Xinerama screens. Xinerama support can be enabled or dis-
abled on the fly or from the configuration file with the
Xinerama command. Many modules and commands work nicely
with Xinerama displays.
Everywhere where a geometry in the usual X format can be
supplied, fvwm's Xinerama extension allows to specify a
screen in addition to the geometry (or even the screen
alone). To do this, a '@' is added to the end of the
geometry string followed by either the screen number or a
letter. A number is taken as the number of the Xinerama
screen to be used (as configured in the X server). The
letter can be one of 'g' for the global screen (the rect-
angle that encloses all Xinerama screens), 'p' for the
primary screen (see below), 'c' for the current screen
(the one that currently contains the pointer). If the X
server does not support Xinerama or only one screen is
used, the screen bit is ignored.
Style * IconBox 64x300-0-0@p
Xinerama support can be configured to use a primary
screen. Fwvm can be configured to place new windows and
icons on this screen. The primary screen is screen 0 by
default but can be changed with the XineramaPrimaryScreen
command.
Xinerama support was designed to work out of the box with
the same configurations file that would work on a single
screen. It may not work too well if the involved screens
use different screen resolutions. In this situation, win-
dows may get stuck in the portion of the whole desktop
that belongs to neither screen. If this happens, the win-
dows or icons can be retrieved with the command
All MoveToScreen
that can be entered in an FvwmConsole window or with Fvwm-
Command.
For multi-screen implementations other than Xinerama, such
as Single Logical Screen, it is possible to simulate a
Xinerama configuration if the total screen seen by FVWM is
made up of equal sized monitors in a rectangular grid.
The commands XineramaSls and XineramaSlsSize are used to
configure this feature.
INITIALIZATION
During initialization, fvwm searches for a configuration
file which describes key and button bindings, and many
other things. The format of these files is described
later. Fvwm first searches for configuration files using
the command
Read .fvwm2rc
This looks for .fvwm2rc in $HOME/.fvwm or $FVWM_USERDIR
directories, as described in Read below. If this fails,
fvwm also searches for this file in the $HOME directory or
for system.fvwm2rc file in the system place. If a config-
uration file is not found, any mouse button or the Help or
F1 keys on the root window brings up menus and forms that
can create a starting configuration file.
Fvwm sets two environment variables which are inherited by
its children. These are $DISPLAY which describes the dis-
play on which fvwm is running. $DISPLAY may be unix:0.0
or :0.0, which doesn't work too well when passed through
rsh to another machine, so $HOSTDISPLAY is set to a net-
work-ready description of the display. $HOSTDISPLAY
always uses the TCP/IP transport protocol (even for a
local connection) so $DISPLAY should be used for local
connections, as it may use Unix-domain sockets, which are
faster.
If you want to start some applications or modules with
fvwm, you can simply put
Exec app
or
Module FvwmXxx
into your .fvwm2rc, but it is not recommended; do this
only if you know what you are doing. It is usually criti-
cal to start applications or modules after .fvwm2rc is
read, because it contains styles or module configurations
which can affect window appearance and functionality.
The standard way to start applications or modules on
fvwm's start up is to add them to an initialization func-
tion (usually StartFunction or InitFunction). This way
they are only started after fvwm reads the entire
.fvwm2rc.
Fvwm has three special functions for initialization:
StartFunction, which is executed on startups and restarts;
InitFunction and RestartFunction, which are executed dur-
ing initialization and restarts (respectively) just after
StartFunction. These functions may be customized in a
user's .fvwm2rc file via the AddToFunc command (described
later) to start up modules, xterms, or whatever you'd like
to have started by fvwm.
Fvwm has also a special exit function: ExitFunction, exe-
cuted when exiting or restarting before actually quitting.
It could be used to explicitly kill modules, etc.
If fvwm is run under a session manager, functions Session-
InitFunction and SessionRestartFunction are executed
instead of InitFunction and RestartFunction. This helps
to define the user's .fvwm2rc file to be good for both
running under a session manager and without it. Generally
it is a bad idea to start xterms or other applications in
"Session*" functions. Also someone can decide to start
different modules while running under a session manager or
not. For the similar purposes SessionExitFunction is used
instead of ExitFunction.
DestroyFunc StartFunction
AddToFunc StartFunction
+ I ModuleSynchronous FvwmTheme
+ I Module FvwmPager * *
+ I Module FvwmButtons
DestroyFunc InitFunction
AddToFunc InitFunction
+ I Module FvwmBanner
+ I Module FvwmTaskBar
+ I xsetroot -solid cyan
+ I Exec xterm
+ I Exec netscape
DestroyFunc RestartFunction
AddToFunc RestartFunction
+ I Module FvwmTaskBar
DestroyFunc SessionInitFunction
AddToFunc SessionInitFunction
+ I Module FvwmBanner
DestroyFunc SessionRestartFunction
AddToFunc SessionRestartFunction
+ I Nop
You don't need to define all special functions if some are
empty.
COMPILATION OPTIONS
Fvwm has a number of compile-time options. If you have
trouble using a certain command or feature, check to see
if support for it was included at compile time. Optional
features are described in the config.h file that is gener-
ated during compilation.
ICONS
The basic fvwm configuration uses monochrome bitmap icons.
If XPM extensions are compiled in, then color icons can be
used. In order to use these options you need the XPM pack-
age, as described in the INSTALL.fvwm file.
If both the SHAPE and XPM options are compiled in you get
shaped color icons, which are very spiffy.
MODULES
A module is a separate program which runs as a separate
Unix process but transmits commands to fvwm to execute.
Users can write their own modules to do any weird or
bizarre manipulations without bloating or affecting the
integrity of fvwm itself.
Modules must be spawned by fvwm so that it can set up two
pipes for fvwm and the module to communicate with. The
pipes are already open for the module when it starts and
the file descriptors for the pipes are provided as command
line arguments.
Modules can be spawned during fvwm at any time during the
X session by use of the Module built-in command. Modules
can exist for the duration of the X session, or can per-
form a single task and exit. If the module is still
active when fvwm is told to quit, then fvwm closes the
communication pipes and waits to receive a SIGCHLD from
the module, indicating that it has detected the pipe clo-
sure and has exited. If modules fail to detect the pipe
closure fvwm exits after approximately 30 seconds anyway.
The number of simultaneously executing modules is limited
by the operating system's maximum number of simultaneously
open files, usually between 60 and 256.
Modules simply transmit text commands to the fvwm built-in
command engine. Text commands are formatted just as in
the case of a mouse binding in the .fvwm2rc setup file.
Certain auxiliary information is also transmitted, as in
the sample module FvwmButtons. The FvwmButtons module is
documented in its own man page.
Please refer to the MODULE COMMANDS section for details.
ICCCM COMPLIANCE
Fvwm attempts to be ICCCM 2.0 compliant. In addition,
ICCCM states that it should be possible for applications
to receive any keystroke, which is not consistent with the
keyboard shortcut approach used in fvwm and most other
window managers. In particular you cannot have the same
keyboard shortcuts working with your fvwm and another fvwm
running within Xnest (a nested X server running in a win-
dow). The same problem exists with mouse bindings.
The ICCCM states that windows possessing the property
WM_HINTS(WM_HINTS):
Client accepts input or input focus: False
should not be given the keyboard input focus by the window
manager. These windows can take the input focus by them-
selves, however. A number of applications set this prop-
erty, and yet expect the window-manager to give them the
keyboard focus anyway, so fvwm provides a window-style,
Lenience, which allows fvwm to overlook this ICCCM rule.
Even with this window-style it is not guaranteed that the
application accepts focus.
The differences between ICCCM 1.1 and 2.0 include the
ability to take over from a running ICCCM 2.0 compliant
window manager; thus
fvwm2; vi .fvwm2rc; fvwm2 -replace
resembles the Restart command. It is not exactly the
same, since killing the previously running wm may termi-
nate your X session, if the wm was started as the last
client in your .Xclients or .Xsession file.
Further additions are support for client-side colormap
installation (see the .SM ICCCM for details) and the
urgency hint. Clients can set this hint in the WM_HINTS
property of their window and expect the window manager to
attract the users attention to the window. Fvwm has two
re-definable functions for this purpose, "UrgencyFunc" and
"UrgencyDoneFunc", which are executed when the flag is
set/cleared. Their default definitions are:
AddToFunc UrgencyFunc
+ I Iconify off
+ I FlipFocus
+ I Raise
+ I WarpToWindow 5p 5p
AddToFunc UrgencyDoneFunc
+ I Nop
GNOME COMPLIANCE
Fvwm attempts to be GNOME compliant. Check
http://www.gnome.org for what that may mean. GNOME sup-
port is a compile time option which is on by default. To
disable GNOME hints for some or all windows, the
GNOMEIgnoreHints style can be used.
MWM COMPATIBILITY
Fvwm provides options to emulate Motif Window Manager
(Mwm) as well as possible. Please refer to the Emulate
command as well as to the Mwm specific options of the
Style and MenuStyle commands for details.
OPEN LOOK and XVIEW COMPATIBILITY
OPEN LOOK and XVIEW COMPATIBILITY
Fvwm supports all the Open Look decoration hints (except
pushpins). Should you use any such application, please
add the following line to your .fvwm2rc:
Style * OLDecor
Most (perhaps all) Open Look applications have a strange
notion of keyboard focus handling. Although a lot of work
went into fvwm to work well with these, you may still
encounter problems. It is recommended to use the NeverFo-
cus focus policy and the NoLenience style for all such
applications (the windows will still get the focus):
Style NeverFocus, NoLenience
But in case you can not live with that focus policy, you
can try using one of the other focus policies in combina-
tion with the Lenience style:
Style MouseFocus, Lenience
Style SloppyFocus, Lenience
Style ClickToFocus, Lenience
M4 PREPROCESSING
M4 pre-processing is handled by a module in fvwm. To get
more details, try man FvwmM4. In short, if you want fvwm
to parse your files with m4, then replace the command Read
with FvwmM4 in your .fvwm2rc file (if it appears at all),
and start fvwm with the command
fvwm2 -cmd "FvwmM4 .fvwm2rc"
CPP PREPROCESSING
Cpp is the C-language pre-processor. fvwm offers cpp pro-
cessing which mirrors the m4 pre-processing. To find out
about it, re-read the M4 section above, but replace "m4"
with "cpp".
AUTO-RAISE
Windows can be automatically raised when it receives
focus, or some number of milliseconds after it receives
focus, by using the auto-raise module, FvwmAuto.
CONFIGURATION FILES
The configuration file is used to describe mouse and but-
ton bindings, colors, the virtual display size, and
related items. The initialization configuration file is
typically called .fvwm2rc. By using the Read built-in, it
is easy to read in new configuration files as you go.
Lines beginning with '#' are ignored by fvwm. Lines
starting with '*' are expected to contain module configu-
ration commands (rather than configuration commands for
fvwm itself). Like in shell scripts embedded newlines in a
configuration file line can be quoted by preceding them
with a backslash. All lines linked in this fashion are
treated as a single line. The newline itself is ignored.
Fvwm makes no distinction between configuration commands
and built-in commands, so anything mentioned in the built-
in commands section can be placed on a line by itself for
fvwm to execute as it reads the configuration file, or it
can be placed as an executable command in a menu or bound
to a mouse button or a keyboard key. It is left as an
exercise for the user to decide which function make sense
for initialization and which ones make sense for run-time.
SUPPLIED CONFIGURATION
A sample configuration file, .fvwm2rc, is supplied with
the fvwm distribution. It is well commented and can be
used as a source of examples for fvwm configuration.
KEYBOARD SHORTCUTS
Almost all window manager operations can be performed from
the keyboard so mouse-less operation should be possible.
In addition to scrolling around the virtual desktop by
binding the Scroll built-in to appropriate keys, Popup,
Move, Resize, and most other built-ins can be bound to
keys. Once a built in function is started the pointer is
moved by using the up, down, left, and right arrows, and
the action is terminated by pressing return. Holding down
the Shift key causes the pointer movement to go in larger
steps and holding down the control key causes the cursor
movement to go in smaller steps. Standard emacs and vi
cursor movement controls ( n, p, f, b, and j, k, h, l )
can be used instead of the arrow keys.
SESSION MANAGEMENT
Fvwm supports session management according to the X Ses-
sion Management Protocol. It saves and restores window
position, size, stacking order, desk, stickiness, shaded-
ness, maximizedness, iconifiedness for all windows. Fur-
thermore, some global state is saved.
Fvwm doesn't save any information regarding styles,
decors, functions or menus. If you change any on these
resources during a session (e.g. by issuing Style commands
or by using various modules), these changes are lost after
saving and restarting the session. To become permanent,
such changes have to be added to the configuration file.
Note further that the current implementation has the fol-
lowing anomaly when used on a multi-screen display: Start-
ing fvwm for the first time, fvwm manages all screens by
forking a copy of itself for each screen. Every copy
knows its parent and issuing a Quit command to any
instance of fvwm kills the master and thus all copies of
fvwm. When you save and restart the session, the session
manager brings up a copy of fvwm on each screen, but this
time they are started as individual instances managing one
screen only. Thus a Quit kills only the copy it was sent
to. This is probably not a very serious problem, since
with session management, you are supposed to quit a ses-
sion through the session manager anyway. If it is really
needed,
Exec exec killall fvwm2
still kills all copies of fvwm. Your system must have the
killall command though.
BOOLEAN ARGUMENTS
A number of commands take one or several boolean argu-
ments. These take a few equivalent inputs: "yes", "on",
"true", "t" and "y" all evaluate to true while "no",
"off", "false", "f" and "n" evaluate to false. Some com-
mands allow "toggle" too which means that the feature is
disabled if it is currently enabled and vice versa.
BUILT IN KEY AND MOUSE BINDINGS
The following commands are built-in to fvwm:
Key Help R A Popup MenuFvwmRoot
Key F1 R A Popup MenuFvwmRoot
Key Tab A M WindowList Root c c NoDeskSort
Key Escape A MC EscapeFunc
Mouse 0 R N Menu MenuFvwmRoot
Mouse 1 TS A FuncFvwmRaiseLowerX Move
Mouse 1 F A FuncFvwmRaiseLowerX Resize
AddToFunc FuncFvwmRaiseLowerX I Raise
+ M $0
+ D Lower
The Help and F1 keys invoke a built-in menu that fvwm cre-
ates. This is primarily for new users that have not cre-
ated their own configuration file. Either key on the root
(background) window pops up an menu to help you get
started.
The Tab key pressed anywhere with the Meta key (same as
the Alt key on PC keyboards) held down pop-ups a window
list.
Mouse button 1 on the title-bar or side frame can move,
raise or lower a window.
Mouse button 1 on the window corners can resize, raise or
lower a window.
You can override or remove these bindings. To remove the
window list binding, use this:
Key Tab A M -
BUILT IN COMMANDS
Fvwm supports a set of built-in functions which can be
bound to keyboard or mouse buttons. If fvwm expects to
find a built-in function in a command, but fails, it
checks to see if the specified command should have been
Function (rest of command)
or
Module (rest of command)
This allows complex functions or modules to be invoked in
a manner which is fairly transparent to the configuration
file.
Example: the .fvwm2rc file contains the line
HelpMe
Fvwm looks for a built-in command called "HelpMe", and
fails. Next it looks for a user-defined complex function
called "HelpMe". If no such user defined function exists,
Fvwm tries to execute a module called "HelpMe".
Note: There are many commands that affect look and feel of
specific, some or all windows, like Style, Mouse, the
FvwmTheme module and many others. For performance reasons
such changes are not applied immediately but only when
fvwm is idle, i.e. no user interaction or module input is
pending. Specifically, new Style options that are set in
a function are not applied until after the function has
completed. This can sometimes lead to unwanted effects.
To force that all pending changes are applied immediately,
use the UpdateStyles, Refresh or RefreshWindow commands.
QUOTING
Quotes are required only when needed to make fvwm consider
two or more words to be a single argument. Unnecessary
quoting is allowed. If you want a quote character in your
text, you must escape it by using the backslash character.
For example, if you have a pop-up menu called "Window-
Ops", then you don't need quotes:
Popup Window-Ops
but if you replace the dash with a space, then you need
quotes:
Popup "Window Ops"
The supported quoting characters are double quotes, single
quotes and reverse single quotes. All three kinds of
quotes are treated in the same way. Single characters can
be quoted with a preceding backslash. Quoting single
characters works even inside other kinds of quotes.
COMMAND EXPANSION
Whenever a fvwm command line is executed, fvwm performs
parameter expansion. A parameter is a '$' followed by a
word enclosed in brackets ($[...]) or a single special
character. If fvwm encounters an unquoted parameter on
the command line it expands it to a string indicated by
the parameter name. Unknown parameters are left
untouched. Parameter expansion is performed before quot-
ing. To quote a '$' use "$$".
In the past some single letter variables were supported.
It is deprecated now, since they cause a number of prob-
lems. You should use the longer substitutes instead.
Example:
# Print the current desk number, horizontal
# page and the window's class.
Echo $[desk.n] $[page.nx] $[w.class]
Note: If the command is called outside a window context,
it will print "$[w.class]" instead of the class name. It
is usually not enough to have the pointer over a window to
have a context window. To force using the window with the
focus, the Current command can be used:
Current Echo $[desk.n] $[page.nx] $[w.class]
The parameters known by fvwm are:
$$
A literal '$'.
$.
The absolute directory of the currently Read file.
Intended for creating relative and relocatable
configuration trees. If used outside of any read
file, the returned value is '.'.
$c
The window's resource class name or "$c" if no
window is associated with the command.
(Deprecated, use $[w.class] instead.)
$d
The current desk number.
(Deprecated, use $[desk.n] instead.)
$n
The window's name or "$n" if no window is associ-
ated with the command.
(Deprecated, use $[w.name] instead.)
$r
The window's resource name or "$r" if no window is
associated with the command.
(Deprecated, use $[w.resource] instead.)
$v
The first line printed by the -version command
line option.
(Deprecated, use $[version.line] instead.)
$w
The window-id (expressed in hex, e.g. 0x10023c) of
the window the command was called for or "$w" if
no window is associated with the command.
(Deprecated, use $[w.id] instead.)
$x
The x coordinate of the current viewport.
(Deprecated, use $[vp.x] instead.)
$y
The y coordinate of the current viewport.
(Deprecated, use $[vp.y] instead.)
$0 to $9
The positional parameters given to a complex func-
tion (a function that has been defined with the
AddToFunc command). "$0" is replaced with the
first parameter, "$1" with the second parameter
and so on. If the corresponding parameter is
undefined, the "$..." is deleted from the command
line.
$*
All positional parameters given to a complex func-
tion. This includes parameters that follow after
"$9".
$[version.num]
The version number, like "2.6.0".
$[version.info]
The version info, like " (from cvs)", empty for
the official releases. (Always empty in this
branch.)
$[version.line]
The first line printed by the -version command
line option.
$[vp.x] $[vp.y] $[vp.width] $[vp.height]
Either coordinate or the width or height of the
current viewport.
$[desk.n]
The current desk number.
$[desk.width] $[desk.height]
The width or height of the whole desktop, i.e. the
width or height multiplied by the number of pages
in x or y direction.
$[desk.pagesx] $[desk.pagesy]
The number of total pages in a desk in x or y
direction. This is the same as the values set by
DesktopSize.
$[page.nx] $[page.ny]
The current page numbers, by X and Y axes, start-
ing from 0. page is equivalent to area in the
GNOME terminology.
$[w.id]
The window-id (expressed in hex, e.g. 0x10023c) of
the window the command was called for or "$[w.id]"
if no window is associated with the command.
$[w.x] $[w.y] $[w.width] $[w.height]
Either coordinate or the width or height of the
current window if it is not iconified. If no win-
dow is associated with the command or the window
is iconified, the string is left as is.
$[w.name] $[w.iconname] $[w.class] $[w.resource]
The window's name or icon name or resource class
or resource name respectivelly, or unexpended
"$[w.]" string if no window is associ-
ated with the command.
$[screen]
The screen number fvwm is running on. Useful for
setups with multiple screens.
$[fg.cs]
$[bg.cs]
$[hilight.cs]
$[shadow.cs]
These class of parameters is replaced with the
name of the foreground (fg), background (bg),
hilight (hilight) or shadow (shadow) color that is
defined in colorset (replace with zero or
a positive integer). For example "$[fg.cs3]" is
expanded to the name of the foreground color of
colorset 3 (in rgb:rrrr/gggg/bbbb form). Please
refer to the man page of the FvwmTheme module for
details about colorsets. Note that although other
parameters cannot be used in module configuration
lines, it is possible to use this class of parame-
ters. They can be used wherever a module expects
a color name. Since the FvwmTheme module is not
running when fvwm first passes through its config-
uration file, you may not get the desired results
if you use this in commands like
Style * HilightFore $[fg.cs0], HilightBack $[bg.cs0]
$[...]
If the string within the braces is neither of the
above, fvwm tries to find an environment variable
with this name and replaces its value if one is
found (e.g. "$[PAGER]" could be replaced by
"more"). Otherwise the string is left as is.
Some examples can be found in the description of the
AddToFunc command.
THE LIST OF BUILTIN COMMANDS
The commands descriptions below are grouped together in
the following sections. The sections are hopefully sorted
in order of usefulness to the newcomer.
- Menu commands
- Miscellaneous commands
- Commands affecting window movement and placement
- Commands for focus and mouse movement
- Commands controlling window state
- Commands for mouse, key and stroke bindings
- The Style command (controlling window styles)
- Other commands controlling window styles
- Commands controlling the virtual desktop
- Commands for user functions and shell commands
- Conditional commands
- Module commands
- Quit, restart and session management commands
- Color gradients
COMMANDS FOR MENUS
AddToMenu menu-name [menu-label action]
Begins or adds to a menu definition. Typically a
menu definition looks like this:
AddToMenu Utilities Utilities Title
+ Xterm Exec exec xterm -e tcsh
+ Rxvt Exec exec rxvt
+ "Remote Logins" Popup Remote-Logins
+ Top Exec exec rxvt -T Top -n \
Top -e top
+ Calculator Exec exec xcalc
+ Xman Exec exec xman
+ Xmag Exec exec xmag
+ emacs Exec exec xemacs
+ Mail MailFunction \
xmh "-font fixed"
+ "" Nop
+ Modules Popup Module-Popup
+ "" Nop
+ Exit Fvwm Popup Quit-Verify
The menu could be invoked via
Mouse 1 R A Menu Utilities Nop
or
Mouse 1 R A Popup Utilities
There is no end-of-menu symbol. Menus do not have
to be defined in a contiguous region of the
.fvwm2rc file. The quoted portion in the above
examples is the menu label, which appears in the
menu when the user pops it up. The remaining por-
tion is a built-in command which should be executed
if the user selects that menu item. An empty menu-
label ("") and the Nop function can be used to
insert a separator into the menu.
The keywords DynamicPopUpAction and DynamicPopDown-
Action have a special meaning when used as the name
of a menu item. The action following the keyword
is executed whenever the menu is popped up or down.
This way you can implement dynamic menus. It is
even possible to destroy itself with DestroyMenu
and the rebuild from scratch. When the menu has
been destroyed (unless you used the recreate option
when destroying the menu), do not forget to add the
dynamic action again.
Note: Do not trigger actions that require user
interaction. They will probably fail and may screw
up your menus. See Silent command.
Warning: Do not issue MenuStyle commands as dynamic
menu actions. Chances are good that this will
crash fvwm.
Example (File browser):
# You can find the shell script
# fvwm_make_browse_menu.sh in the utils
# directory of the distribution.
AddToMenu BrowseMenu
+ DynamicPopupAction Piperead \
'fvwm_make_browse_menu.sh BrowseMenu'
Example (Picture menu):
# Build a menu of all .jpg files in
# $HOME/Pictures
AddToMenu JpgMenu foo title
+ DynamicPopupAction Function MakeJpgMenu
AddToFunc MakeJpgMenu
+ I DestroyMenu recreate JpgMenu
+ I AddToMenu JpgMenu Pictures Title
+ I PipeRead 'for i in $HOME/Pictures/*.jpg; \
do echo AddToMenu JpgMenu "`basename $i`" Exec xv $i; done'
The keyword MissingSubmenuFunction has a similar
meaning. It is executed whenever you try to pop up
a sub-menu that does not exist. With this function
you can define and destroy menus on the fly. You
can use any command after the keyword, but the name
of a function defined with AddToFunc follows it,
fvwm executes this command:
Function
I.e. the name is passed to the function as its
first argument and can be referred to with "$0".
Example:
# There is another shell script
# fvwm_make_directory_menu.sh in the utils
# directory of the distribution. To use it,
# define this function in your configuration
# file:
AddToFunc MakeMissingDirectoryMenu
+ I Exec fvwm_make_directory_menu.sh $0
AddToMenu SomeMenu
+ MissingSubmenuFunction MakeMissingDirectoryMenu
+ "Root directory" Popup /
This is another implementation of the file browser
that uses sub-menus for subdirectories.
Titles can be used within the menu. If you add the
option top behind the keyword Title, the title is
added to the top of the menu. If there was a title
already, it is overwritten.
AddToMenu Utilities Tools Title top
All text up to the first Tab in the menu label is
aligned to the left side of the menu, all text
right of the first Tab is aligned to the left in a
second column and all text thereafter is placed
right aligned in the third column. All other Tabs
are replaced by spaces. Note that you can change
this format with the ItemFormat option of the
MenuStyle command.
If the menu-label contains an ampersand ('&'), the
next character is taken as a hot-key for the menu
item. Hot-keys are underlined in the label. To
get a literal '&', insert "&&". Pressing the hot-
key moves through the list of menu items with this
hot-key or selects an item that is the only one
with this hot-key.
If the menu-label contains a sub-string which is
set off by stars, then the text between the stars
is expected to be the name of an xpm-icon or
bitmap-file to insert in the menu. To get a lit-
eral '*', insert "**". For example
+ Calculator*xcalc.xpm* Exec exec xcalc
inserts a menu item labeled "Calculator" with a
picture of a calculator above it. The following:
+ *xcalc.xpm* Exec exec xcalc
Omits the "Calculator" label, but leaves the pic-
ture.
If the menu-label contains a sub-string which is
set off by percent signs, then the text between the
percent signs is expected to be the name of an xpm-
icon or bitmap-file (a so called mini icon to
insert to the left of the menu label. A second
mini icon that is drawn at the right side of the
menu can be given in the same way. To get a lit-
eral '%', insert "%%". For example
+ Calculator%xcalc.xpm% Exec exec xcalc
inserts a menu item labeled "Calculator" with a
picture of a calculator to the left. The follow-
ing:
+ %xcalc.xpm% Exec exec xcalc
Omits the "Calculator" label, but leaves the pic-
ture. The pictures used with this feature should
be small (perhaps 16x16). If the menu-name (not
the label) contains a sub-string which is set off
by at signs ('@'), then the text between them is
expected to be the name of an xpm or bitmap file to
draw along the left side of the menu (a side
pixmap). You may want to use the SidePic option of
the MenuStyle command instead. To get a literal
'@', insert "@@". For example
AddToMenu StartMenu@linux-menu.xpm@
creates a menu with a picture in its bottom left
corner.
If the menu-name also contains a sub-string sur-
rounded by '^'s, then the text between '^'s is
expected to be the name of an X11 color and the
column containing the side picture is colored with
that color. You can set this color for a menu
style using the SideColor option of the MenuStyle
command. To get a literal '^', insert "^^". Exam-
ple:
AddToMenu StartMenu@linux-menu.xpm@^blue^
creates a menu with a picture in its bottom left
corner and colors with blue the region of the menu
containing the picture.
In all the above cases, the name of the resulting
menu is name specified, stripped of the substrings
between the various delimiters.
ChangeMenuStyle menustyle menu ...
Changes the menu style of menu to menustyle. You
may specified more than one menu in each call of
ChangeMenuStyle.
ChangeMenuStyle pixmap1 \
ScreenSaverMenu ScreenLockMenu
CopyMenuStyle orig-menustyle dest-menustyle
Copy orig-menustyle to dest-menustyle, where orig-
menustyle is an existing menu style. If the menu
style dest_menustyle does not exist, then it is
created.
DestroyMenu [recreate] menu
Deletes a menu, so that subsequent references to it
are no longer valid. You can use this to change
the contents of a menu during an fvwm session. The
menu can be rebuilt using AddToMenu. The optional
parameter recreate tells fvwm not to throw away the
menu completely but to throw away all the menu
items (including the title).
DestroyMenu Utilities
DestroyMenuStyle menustyle
Deletes the menu style named menustyle and changes
all menus using this style to the default style,
you cannot destroy the default menu style.
DestroyMenuStyle pixamp1
Menu menu-name [ position ] [ double-click-action ]
Causes a previously defined menu to be popped up in
a sticky manner. That is, if the user invokes the
menu with a click action instead of a drag action,
the menu stays up. The command double-click-action
is invoked if the user double-clicks a button (or
hits the key rapidly twice if the menu is bound to
a key) when bringing up the menu. If the double
click action is not specified, double clicking on
the menu does nothing. However, if the menu begins
with a menu item (i.e. not with a title or a sepa-
rator) and the double click action is not given,
double clicking invokes the first item of the menu
(but only if the pointer really was over the item).
Several other commands affect menu operation. See
MenuStyle and SetAnimation. When in a menu, key-
board shortcuts work as expected. Cursor
keystrokes are also allowed. Specifically, Tab,
Meta-Tab, Cursor-Down, Ctrl-N, or Ctrl-J move to
the next item; Shift-Tab, Shift-Meta-Tab, Cursor-
Up, Ctrl-P, or Ctrl-K move to the prior item; Cur-
sor-Left or Ctrl-B returns to the prior menu; Cur-
sor-Right or Ctrl-F pop up the next menu; Ctrl-Cur-
sor-Up, Shift-Ctrl-Meta-Tab and Page-Up move up
five items; Ctrl-Cursor-Down, Ctrl-Meta-Tab and
Page-Down move down five items, respectively; Home,
Shift-Cursor-Up or End, Shift-Cursor-Down move to
the first or last item, respectively; Meta-Cursor-
Up or Meta-Cursor-Down move just behind the next or
previous separator; Shift-Ctrl-Tab or Ctrl-Tab work
exactly the same; Enter, Return, or Space executes
the current item; Insert opens the "More..." sub-
menu if any; Escape and Delete exit the current
sequence of menus.
The pointer is warped to where it was when the menu
was invoked if it was both invoked and terminated
with a keystroke.
The position arguments allow placement of the menu
somewhere on the screen, for example centered on
the visible screen or above a title bar. Basically
it works like this: you specify a context-rectangle
and an offset to this rectangle by which the upper
left corner of the menu is moved from the upper
left corner of the rectangle. The position argu-
ments consist of several parts:
[context-rectangle] x y [special-options]
The context-rectangle can be one of:
Root
the root window of the current screen.
XineramaRoot
the root window of the whole Xinerama
screen. Equivalent to "root" when Xinerama
is not used.
Mouse
a 1x1 rectangle at the mouse position.
Window
the window with the focus.
Interior
the inside of the focused window.
Title
the title of the focused window or icon.
Button
button #n of the focused window.
Icon
the focused icon.
Menu
the current menu.
Item
the current menu item.
Context
the current window, menu or icon.
This
whatever widget the pointer is on (e.g. a
corner of a window or the root window).
Rectangle
the rectangle defined by in X
geometry format. Width and height default
to 1 if omitted.
If the context-rectangle is omitted or illegal
(e.g. "item" on a window), "Mouse" is the default.
Note that not all of these make sense under all
circumstances (e.g. "Icon" if the pointer is on a
menu).
The offset values x and y specify how far the menu
is moved from it's default position. By default,
the numeric value given is interpreted as a per-
centage of the context rectangle's width (height),
but with a trailing 'm' the menu's width (height)
is used instead. Furthermore a trailing 'p'
changes the interpretation to mean pixels.
Instead of a single value you can use a list of
values. All additional numbers after the first one
are separated from their predecessor by their sign.
Do not use any other separators.
If x or y are prefixed with "o" where is an integer, the menu and the rectangle are
moved to overlap at the specified position before
any other offsets are applied. The menu and the
rectangle are placed so that the pixel at
percent of the rectangle's width/height is right
over the pixel at percent of the menu's
width/height. So "o0" means that the top/left bor-
ders of the menu and the rectangle overlap, with
"o100" it's the bottom/right borders and if you use
"o50" they are centered upon each other (try it and
you will see it is much simpler than this descrip-
tion). The default is "o0". The prefix "o" is an abbreviation for "+-m".
A prefix of 'c' is equivalent to "o50". Examples:
# window list in the middle of the screen
WindowList Root c c
# menu to the left of a window
Menu name window -100m c+0
# popup menu 8 pixels above the mouse pointer
Popup name mouse c -100m-8p
# somewhere on the screen
Menu name rectangle 512x384+1+1 +0 +0
# centered vertically around a menu item
AddToMenu foobar-menu
+ "first item" Nop
+ "special item" Popup "another menu" item \
+100 c
+ "last item" Nop
# above the first menu item
AddToMenu foobar-menu
+ "first item" Popup "another menu" item \
+0 -100m
Note that you can put a sub-menu far off the cur-
rent menu so you could not reach it with the mouse
without leaving the menu. If the pointer leaves
the current menu in the general direction of the
sub-menu the menu stays up.
The special-options:
The animated and Mwm or Win menu styles may
move a menu somewhere else on the screen. If
you do not want this you can add Fixed as an
option. This might happen for example if you
want the menu always in the top right corner
of the screen.
Where do you want a menu to appear when you
click on it's menu item? The default is to
place the title under the cursor, but if you
want it where the position arguments say, use
the SelectInPlace option. If you want the
pointer on the title of the menu, use Select-
Warp too. Note that these options apply only
if the PopupAsRootMenu MenuStyle option is
used.
The pointer is warped to the title of a sub-
menu whenever the pointer would be on an item
when the sub-menu is popped up (fvwm menu
style) or never warped to the title at all
(Mwm or Win menu styles). You can force (for-
bid) warping whenever the sub-menu is opened
with the WarpTitle (NoWarp) option.
Note that the special-options do work with a
normal menu that has no other position argu-
ments.
MenuStyle stylename options
Sets a new menu style or changes a previously
defined style. The stylename is the style name; if
it contains spaces or tabs it has to be quoted.
The name "*" is reserved for the default menu
style. The default menu style is used for every
menu-like object (e.g. the window created by the
WindowList command) that had not be assigned a
style using the ChangeMenuStyle. See also Destroy-
MenuStyle. When using monochrome color options are
ignored.
options is a comma separated list containing some
of the keywords Fvwm / Mwm / Win, BorderWidth,
Foreground, Background, Greyed, HilightBack /
HilightBackOff, ActiveFore / ActiveForeOff, Menu-
Colorset, ActiveColorset, GreyedColorset,
Hilight3DThick / Hilight3DThin / Hilight3DOff,
Hilight3DThickness, Animation / AnimationOff, Font,
MenuFace, PopupDelay, PopupOffset, TitleWarp /
TitleWarpOff, TitleUnderlines0 / TitleUnderlines1 /
TitleUnderlines2, SeparatorsLong / SeparatorsShort,
TrianglesSolid / TrianglesRelief, PopupImmediately
/ PopupDelayed, PopdownImmediately / PopdownDe-
layed, DoubleClickTime, SidePic, SideColor, Popu-
pAsRootMenu / PopupAsSubmenu, RemoveSubmenus /
HoldSubmenus, SubmenusRight / SubmenusLeft, Selec-
tOnRelease, ItemFormat, VerticalItemSpacing,
VerticalTitleSpacing, AutomaticHotkeys / Automati-
cHotkeysOff.
In the above list some options are listed as option
pairs or triples with a '/' in between. These
options exclude each other.
Fvwm, Mwm, Win reset all options to the style with
the same name in former versions of fvwm. The
default for new menu styles is Fvwm style. These
options override all others except Foreground,
Background, Greyed, HilightBack, HilightFore and
PopupDelay, so they should be used only as the
first option specified for a menu style or to reset
the style to defined behavior. The same effect can
be created by setting all the other options one by
one.
Mwm and Win style menus popup sub-menus automati-
cally. Win menus indicate the current menu item by
changing the background to dark. Fvwm sub-menus
overlap the parent menu, Mwm and Win style menus
never overlap the parent menu.
Fvwm style is equivalent to HilightBackOff,
Hilight3DThin, ActiveForeOff, AnimationOff, Font,
MenuFace, PopupOffset 0 67, TitleWarp, TitleUnder-
lines1, SeparatorsShort, TrianglesRelief, PopupDe-
layed, PopdownDelayed, PopupAsSubmenu, HoldSub-
menus, SubmenusRight, BorderWidth 2, Automati-
cHotkeysOff.
Mwm style is equivalent to HilightBackOff,
Hilight3DThick, ActiveForeOff, AnimationOff, Font,
MenuFace, PopupOffset -3 100, TitleWarpOff, Title-
Underlines2, SeparatorsLong, TrianglesRelief, Pop-
upImmediately, PopdownDelayed, PopupAsSubmenu,
HoldSubmenus, SubmenusRight, BorderWidth 2, Auto-
maticHotkeysOff.
Win style is equivalent to HilightBack,
Hilight3DOff, ActiveForeOff, AnimationOff, Font,
MenuFace, PopupOffset -5 100, TitleWarpOff, Title-
Underlines1, SeparatorsShort, TrianglesSolid, Pop-
upImmediately, PopdownDelayed, PopupAsSubmenu,
RemoveSubmenus, SubmenusRight, BorderWidth 2, Auto-
maticHotkeysOff.
BorderWidth takes the thickness of the border
around the menus in pixels. It may be zero to 50
pixels. The default is 2. Using an illegal value
reverts the border width to the default.
Foreground and Background may have a color name as
an argument. This color is used for menu text or
the menu's background. You can omit the color name
to reset these colors to the built in default.
Greyed may have a color name as an argument. This
color is the one used to draw a menu-selection
which is prohibited (or not recommended) by the Mwm
hints which an application has specified. If the
color is omitted the color of greyed menu entries
is based on the background color of the menu.
HilightBack and HilightBackOff switch hilighting
the background of the selected menu item on and
off. A specific background color may be used by
providing the color name as an argument to Hilight-
Back. If you use this option without an argument
the color is based on the menu's background color.
ActiveFore and ActiveForeOff switch hilighting
the foreground of the selected menu item on and
off. A specific foreground color may be used by
providing the color name as an argument to Active-
Fore. Omitting the color name has the same effect
as using ActiveForeOff.
MenuColorset controls if a colorset is used instead
of the Foreground, Background and MenuFace menu
styles. If the MenuColorset keyword is followed by
a number equal to zero or greater, this number is
taken as the number of the colorset to use. If the
number is omitted, the colorset is switched off and
the regular menu styles are used again. The fore-
ground and background colors of the menu items are
replaced by the colors from the colorset. If the
colorset has a pixmap defined, this pixmap is used
as the background of the menu. Note that the Menu-
Face menu style has been optimized for memory con-
sumption and may use less memory than the back-
ground from a colorset. The shape mask from the
colorset is used to shape the menu. Please refer
to the description of the Colorset command and the
documentation of the FvwmTheme module for details
about colorsets.
ActiveColorset works exactly like MenuColorset, but
the foreground from the colorset replaces the color
given with the ActiveFore menu style and the col-
orset's background color replaces the color given
with the HilightBack command (to turn on background
hilighting you have to use the HilightBack menu
style too). If specified, the hilight and shadow
colors from the colorset are used too. The pixmap
and shape mask from the colorset are not used.
GreyedColorset works exactly like MenuColorset, but
the foreground from the colorset replaces the color
given with the Greyed menu style. No other parts
of the colorset are used.
Hilight3DThick, Hilight3DThin and Hilight3DOff
determine if the selected menu item is hilighted
with a 3D relief. Thick reliefs are two pixels
wide, thin reliefs are one pixel wide.
Hilight3DThickness takes one numeric argument that
may be between -50 and +50 pixels. With negative
values the menu item gets a pressed in look. The
above three commands are equivalent to a thickness
of 2, 1 and 0.
Animation and AnimationOff turn menu animation on
or off. When animation is on, sub-menus that don't
fit on the screen cause the parent menu to be
shifted to the left so the sub-menu can be seen.
Font takes a font name as an argument. If a font
by this name exists it is used for the text of all
menu items. If it does not exist or if the name is
left blank the built in default is used.
MenuFace enforces a fancy background upon the
menus. You can use the same options for MenuFace
as for the ButtonStyle. See description of Button-
Style command and the COLOR GRADIENTS sections for
more information. If you use MenuFace without
arguments the style is reverted back to normal.
Some examples of MenuFaces are:
MenuFace DGradient 128 2 lightgrey 50 blue 50 \
white
MenuFace TiledPixmap texture10.xpm
MenuFace HGradient 128 2 Red 40 Maroon 60 \
White
MenuFace Solid Maroon
Note: The gradient styles H, V, B and D are opti-
mized for high speed and low memory consumption in
menus. This is not the case for all the other gra-
dient styles. They may be slow and consume huge
amounts of memory, so if you encounter performance
problems with them you may be better off by not
using them. To improve performance you can try one
or all of the following:
Turn hilighting of the active menu item other than
foreground color off:
MenuStyle