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, and the executable program is
named fvwm. There is an fvwm offspring called fvwm95, it
is mostly a patch for fvwm-2.0.43. The main goal of
fvwm95 was to supply a Windows 95 like look and feel.
Since then fvwm has been greatly enhanced and practically
all fvwm95 features can be imitated by fvwm.

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 action commands that most window-man
agers make. Configuration commands typically set fonts,
colors, menu contents, key and mouse function bindings,
while action commands do things like raise and lower win
dows. 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 sepa rately specified for different window groups. 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, mov
ing the pointer over a NeverFocus decoration window won't deprive the terminal of focus.

OPTIONS

These are the command line options that are recognized by
fvwm:

Array------------|-----------------------------------------where "I cc" means a "IxIxI color cube"

These defaults may change before version 2.6. Note
that if you use a private color map (i.e., fvwm is
started with the -C or the -I options), then others
defaults are used.

Now what to do if you encounter problems with col
ors? The first thing to do is to check if you
really cannot run your X server with depth 15, 16
or better. Check your X server documentation. Note
that some hardware can support two different depths
on the same screen (typically depth 8 and depth
24). If depth 8 is the default, you can force fvwm
to use the best depth by using the C option with
TrueColor as argument. So now we assume that you are forced to run in depth 8 with a dynamic visual
because your hardware/driver cannot do better or
because you need to use an application which needs
to run under this mode (e.g., because this applica
tion needs read-write colors). What it should be
understand is that you have only 256 colors and
that all the applications which uses the default
color map must share these colors. The main problem
is that there are applications which use a lot or
even all the colors. If you use such application
you will have no more free colors and some applica
tions (which used only a few colors) may fail to
start or are unusable. There are three things that
can be done (and fvwm does not really play a par
ticular role, all applications are concerned). The
first is to run the applications which waste your
(default) color map with a private color map. For
example, run netscape with the -install option, run
KDE/QT applications with the --cmap option, use the
-C option for fvwm. The disadvantage of this method
is that it is visually disturbing (see the Col
ormapFocus command for a better control of the color maps switching). The second method is to
limit the number of colors that the applications
used. Again, some applications have options to
specify a given color limit. With fvwm you may try
various values, 61 (a special "visual" palette), 56
(a 4x4x3 color cubes plus 6 grey), 29 (a 3x3x3
color cube plus 2 grey), 10 or 9. Also, you may use
the -L option. However, limiting the number of
colors is not the definitive solution. The defini
tive solution is to try cause applications which
use a lot of colors use the same colors. This is a
difficult task as there are no formal standards for
this goal. However, some toolkits as QT and GTK
use color cubes as palettes. So, the idea is to
configure your applications/toolkits to all use the
same color cube. Moreover, you can use the colors
in this color cube in your X resources configura
tion files and/or as arguments to colors options.
fvwm can use any color cube of the form RxGxB with
2 <= R <= 6, R = G, R-1 =< B <= R and B >= 2. To
get an RxGxB color cube give an argument to -l an
integer c >= R*G*B and < (R+1)*(G+1)*B if B=R and <
R*G*(B+1) if B < R (and different from 61). If c >
R*G*B, then some grey may be added to the color
cube. You can use the PrintInfo Colors [1] command to get information on your fvwm colors setting. In
particular, this command prints the palette used by
fvwm in rgb format (the last integer gives the num
ber of times fvwm has allocated the colors).

-L | --strict-color-limit

If the screens display 256 colors (or less) and has
a dynamic visual, causes fvwm to use its palette
for all the colors. By default, the palette is used
only for images and gradients.

-P | --visual-palette

If the screen displays 256 colors (or less) and has
a dynamic visual, this option causes fvwm to use a
palette designed for limiting the "visual" color
distance between the points of the palette. More
over, for better color sharing, if possible colors
with a name in the X rgb data base are used for
defining the colors (with the hope that applica
tions and images will prefer to use named colors).
If the -l option is not used this palette has 61
colors. This palette is also automatically selected
if 61 or 9 is used as argument to the -l option.

-A | --allocate-palette

If the screen displays 256 colors (or less) and has
a dynamic visual this option causes fvwm to allo
cate all the colors of its palette at start up for
reserving these colors for future use. This option
forces the .B -static-palette option. By default,
fvwm allocates (reserves) a color in its palette
only if it needs this color.

-S | --static-palette

If the screen displays 256 colors (or less) and has
a dynamic visual this option causes fvwm to never
free the colors in its palette. By default, when
fvwm does not need a color any more it frees this
color so that a new color can be used. This option
may speed up image loading and save a few bits of
memory.

-blackout

This option is provided for backward compatibility
only. Blacking out the screen during startup is
not necessary anymore.

--debug-stack-ring

Enables stack ring debugging. This option is only
intended for internal debugging and should only be
used by developers.

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.

With the built-in minimal configuration, dragging mouse
button 1 in the frame or side-bars begins a resize opera
tion on the window. Dragging mouse button 2 in the frame
or side-bars begins a move operation. There are
raise/lower operations bound to a single clicking on bor
ders. Similarly for the window title.

Up to ten title-bar buttons may exist. Their use is com
pletely user definable. One popular configuration uses
one button on the left that is used to bring up a list of
window options and two buttons on the right used to
iconify and maximize the window. Another popular configu
ration adds a close button to the right. The number of
title-bar buttons used depends on which ones have mouse
actions bound to them. See the section on the Mouse com
mand 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 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. Windows
may also be listed, along with their geometries, in a win
dow 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
StartsOnPage or StartsOnScreen style specification (the successors 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
desktop.

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 for 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 for specifying 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 for specifying
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. Fvwm 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, XineramaSlsSize and Xinera maSlsScreens 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 AND IMAGES

Fvwm can load .xbm, .xpm, and .png images. XBM images are monochrome. Fvwm can always display XBM files. XPM and PNG formats are color images. Compile-time options deter
mine whether fvwm can display XPM or PNG icons and images. See the INSTALL.fvwm file for more information.

The related SHAPE compile-time option can make fvwm dis
play spiffy shaped icons.

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 command. Modules can exist for the duration of the X session, or can perform 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 closure and has exited. If
modules fail to detect the pipe closure fvwm exits after
approximately 30 seconds anyway. The number of simultane
ously executing modules is limited by the operating sys
tem's maximum number of simultaneously open files, usually
between 60 and 256.

Modules simply transmit commands to the fvwm command
engine. Commands are formatted just as in the case of a
mouse binding in the .fvwm2rc setup file. Certain auxil iary 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

fvwm; vi .fvwm2rc; fvwm -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.

EXTENDED WINDOW MANAGER HINTS

Fvwm attempts to respect the extended window manager hints
(ewmh or EWMH for short) specification:
http://www.freedesktop.org/standards/wm-spec.html and some extensions of this specification. This allows fvwm to
work with KDE version >= 2, GNOME version 2 and other
applications which respect this specification (any appli
cation based on GTK+ version 2). Applications which
respect this specification are called ewmh compliant
applications.

This support is a compile time option. If selected at
compile time, this support is configurable with styles and
commands.

These styles and commands have EWMH as the prefix (so you
can find them easily in this man page).

There is a new Context 'D' for the Key, PointerKey, Mouse and Stroke commands. This context is for desktop applica
tions (such as kdesktop and Nautilus desktop).

When a compliant taskbar asks fvwm to activate a window
(typically when you click on a button which represents a
window in such a taskbar), then fvwm calls the complex
function EWMHActivateWindowFunc which by default is Iconify Off, Focus and Raise. You can redefine this func
tion. For example:

DestroyFunc EWMHActivateWindowFunc
AddToFunc EWMHActivateWindowFunc I Iconify Off
+ I Focus
+ I Raise
+ I WarpToWindow 50 50

additionally warps the pointer to the center of the win
dow.

The EWMH specification introduces the notion of Working
Area. Without ewmh support the Working Area is the full
visible screen (or all your screens if you have a multi
head setup and you use Xinerama). However, compliant
applications (such as a panel) can ask to reserve space at
the edge of the screen. If this is the case, the Working
Area is your full visible screen minus these reserved
spaces. If a panel can be hidden by clicking on a button
the Working Area does not change (as you can unhide the
panel at any time), but the Dynamic Working Area is
updated: the space reserved by the panel is removed (and
added again if you pop up the panel). The Dynamic Working
Area may be used when fvwm places or maximizes a window.
To know if an application reserves space you can type
"xprop | grep _NET_WM_STRUT" in a terminal and select the
application. If four numbers appear then these numbers
define the reserved space as explained in the EwmhBaseS truts command.

This support can be disabled at compile time (use the
--disable-ewmh option to configure).

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

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 <application name> 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 <application name> MouseFocus, Lenience
Style <application name> SloppyFocus, Lenience
Style <application name> 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

fvwm -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 command, 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 action commands, so anything mentioned in the fvwm
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.

FONT NAMES AND FONT LOADING

The fonts used for the text of a window title, icon
titles, menus and geometry window can be specified by
using the Font and IconFont Style, the Font MenuStyle and
the DefaultFont command. Also, all the Modules which use
text have configuration command(s) to specify font(s). All
these styles and commands take a font name as an argument.
This section explains what is a font name for fvwm and
which fonts fvwm loads.

ArrayEach simple font name is tried until a matching font with
the locale charset is found and if this fails each simple
font name is tried without constraint on the charset.

More details on the XLFD can be found in the X manual
page, the X Logical Font Description Conventions document
(called xlfd) and the XLoadFont and XCreateFontSet manual
pages. Some useful font utilities are: xlsfonts,
xfontsel, xfd and xset.

ArrayThe "first" font which matches the description is loaded.
This first font depends on the XftConfig configuration
file with Xft1 and on the /etc/fonts/fonts.conf file with
Xft2. One may read the Xft manual page and the fontconfig
man page with Xft2. The first string which follows "xft:"
is always considered as the family. With the second exam
ple Luxi Mono is the Family (Other XFree TTF families:
"Luxi Serif", "Luxi Sans"), Medium is the Weight (other
possible weights: Light, DemiBold, Bold, Black), Roman is
the slant or the style (other possibility: Regular,
Oblique, Italic) size specifies the point size (for a
pixel size use pixelsize=), encoding allows for enforce a
charset (iso8859-1 or iso10646-1 only; if no encoding is
given the locale charset is assumed). An important param
eter is "minspace=bool" where bool is True or False. If
bool is False (the default?) Xft gives a greater font
height to fvwm than if bool is True. This may modify text
placement, icon and window title height, line spacing in
menus and FvwmIdent, button height in some fvwm modules
...etc. With a LCD monitor you may try to add "rgba=mode"
where mode is either rgb, bgr, vrgb or vbgr to enable sub
pixel rendering. The best mode depends on the way your LCD
cells are arranged. You can pass other specifications in
between ":", as "foundry=foundry_name", "spacing=type"
where type can be monospace, proportional or charcell,
"charwidth=integer", "charheight=integer" or
"antialias=bool" where bool is True or False. It seems
that these parameters are not always taken in account. To
determine which Xft fonts are really loaded you can export
XFT_DEBUG=1 before starting fvwm and take a look to the
error log. With Xft2 you may use fc-list to list the
available fonts. Anyway, Xft support is experimental
(from the X and the fvwm point of view) and the quality of
the rendering depends on number of parameters (the XFree
and the freetype versions and your video card(s)).

Arraythen, if either loading the Xft font fails or fvwm has no
Xft support, fvwm loads the font "-adobe-courier-bold-rnormal--14-*". This allows for writing portable configura
tion files.

FONT AND STRING ENCODING

Once a font is loaded, fvwm finds its encoding (or
charset) using its name (the last two fields of the name).
fvwm assumes that the strings which are displayed with
this font use this encoding (an exception is that if an
iso10646-1 font is loaded, then UTF-8 is assumed for
string encoding). In a normal situation, (i) a font is
loaded by giving a font name without specifying the encod
ing, (ii) the encoding of the loaded font is the locale
encoding, and then (iii) the strings in the fvwm configu
ration files should use the locale encoding as well as the
window and icon name. With Xft the situation is bit dif
ferent as Xft supports only iso10646-1 and iso8859-1. If
you do not specify one of these encodings in the Xft font
name, then fvwm does strings conversion using (iii). Note
that with multibyte fonts (and in particular with "CJK"
fonts) for good text rendering, the locale encoding should
be the charset of the font.

Arrayto force fvwm to use the font with iso8859-6 as the encod
ing (this is useful for bi-directionality) and to use
local_iso8859_6_iconv for defining the converters.

FONT SHADOW EFFECTS

Fonts can be given 3d effects. At the beginning of the
font name (or just after a possible StringEncoding
specification) add

Shadow=size [offset] [directions]:

size is a positive integer which specifies the number of
pixels of shadow. offset is an optional positive integer which defines the number of pixels to offset the shadow
from the edge of the character. The default offset is
zero. directions is an optional set of directions the shadow emanates from the character. The directions are a space separated list of fvwm directions:

N, North, Top, t, Up, u

E, East, Right, r, Right, r

S, South, Bottom, b, Down, d

W, West, Left, l, Left, l

NE, NorthEast, TopRight, tr, UpRight, ur

SE, SouthEast, BottomRight, br, DownRight, dr

SW, SouthWest, BottomLeft, bl, DownLeft, dl

NW, NorthWest, TopLeft, tl, UpLeft, ul

C, Center, Centre

a shadow is displayed in each given direction. All is
equivalent to all the directions. The default direction is BottomRight. With the Center direction, the shadow surrounds the whole string. Since this is a super set of
all other directions, it is a waste of time to specify
this along with any other directions.

The shadow effect only works with colorsets. The color of
the shadow is defined by using the fgsh option of the Col_ orset command. Please refer to the COLORSETS section for details about colorsets.

Note: It can be difficult to find the font, fg, fgsh and bg colors to make this effect look good, but it can look
quite good.

BI-DIRECTIONAL TEXT

Arabic and Hebrew text require bi-directional text support
to be displayed correctly, this means that logical strings
should be converted before their visual presentation, so
left-to-right and right-to-left sub-strings are determined
and reshuffled. In fvwm this is done automatically in
window titles, menus, module labels and other places if
the fonts used for displaying the text are of one of the
charsets that require bidi (bi-directional) support. For
example, this includes iso8859-6, iso8859-8 and iso10646-1
(unicode), but not other iso8859-* fonts.

This bi-directional text support is done using the fribidi library compile time option, see INSTALL.fvwm.

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 command to appropriate keys, Popup, Move, Resize, and any other command can be bound to keys. Once a command 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 pointer movement
to go in smaller steps. Standard emacs and vi cursor move
ment 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 fvwm

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.

CONDITIONAL COMMANDS AND RETURN CODES

Fvwm recognizes a number of commands that are executed
only if certain conditions are met. For a complete
description, please refer to the section CONDITIONAL COM MANDS below.

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 1 R A Menu MenuFvwmRoot
Mouse 1 T A FuncFvwmRaiseLowerX Move
Mouse 1 FS A FuncFvwmRaiseLowerX Resize
Mouse 2 FST A FuncFvwmRaiseLowerX Move
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

MODULE AND FUNCTION COMMANDS

If fvwm encounters a command that it doesn't recognize, 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 an fvwm command called "HelpMe", and fails.
Next it looks for a user-defined complex function called
"HelpMe". If no such function exists, fvwm tries to exe
cute a module called "HelpMe".

DELAYED EXECUTION OF COMMANDS

Note: There are many commands that affect look and feel of
specific, some or all windows, like Style, Mouse, Col orset,, TitleStyle 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 "WindowOps", 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.

ArrayEcho $[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 '.'.

$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.

$[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.name<n>]

These parameters are replaced with the name of the
desktop number <n> that is defined with the Desk
topName command. If no name is defined, then the default name is returned.

$[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.name] $[w.iconname] $[w.class] $[w.resource]

The window's name or icon name or resource class
or resource name respectivelly, or unexpended
"$[w.<attribute>]" string if no window is associ
ated 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.

$[cw.x] $[cw.y] $[cw.width] $[cw.height]

These work like $[w....] but return the geometry
of the client part of the window. In other words:
the border and title of the window is not taken
into account.

$[i.x], $[it.x], $[ip.x] $[i.y], $[it.y], $[ip.y]
$[i.width], $[it.width], $[ip.width] $[i.height],
$[it.height], $[ip.height]

These work like $[w....] but return the geometry
of the icon ($[i....]), the icon title ($[it....])
or the icon picture ($[ip....]).

$[pointer.x] $[pointer.y]

These return the position of the pointer on the
screen. If the pointer is not on the screen,
these variables are not expanded.

$[pointer.wx] $[pointer.wy]

These return the position of the pointer in the
selected window. If the pointer is not on the
screen, the window is iconified or no window is
selected, these variables are not expanded.

$[pointer.cx] $[pointer.cy]

These return the position of the pointer in the
client portion of the selected window. If the
pointer is not on the screen, the window is shaded
or iconified or no window is selected, these vari
ables are not expanded.

$[screen]

The screen number fvwm is running on. Useful for
setups with multiple screens.

$[fg.cs<n>]
$[bg.cs<n>]
$[hilight.cs<n>]
$[shadow.cs<n>]

These parameters are replaced with the name of the
foreground (fg), background (bg), hilight
(hilight) or shadow (shadow) color that is defined
in colorset <n> (replace <n> with zero or a posi
tive 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 COLORSETS section for details about colorsets.

$[schedule.last]

This is replaced by the id of the last command
that was scheduled with the Schedule command, even if this command was already executed.

$[schedule.next]

This is replaced by the id the next command used
with Schedule will get (unless a different id is specified explicitly).

$[cond.rc]

The return code of the last conditional command.
This variable is only valid inside a function and
can not be used in a conditional command. Please
refer to the section CONDITIONAL COMMANDS in the command list.

$[gt.str]

return the translation of str by looking in the
current locale catalog(s). If no translation is
found str is returned as is. See the LocalePath command.

$[...]

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.

SCRIPTING AND COMPLEX FUNCTIONS

To achieve the more complex effects, fvwm has a number of
commands that improve its scripting abilities. Scripts
can be read from a file with Read, from the output of a
command with PipeRead or written as a complex function with the AddToFunc command. For the curious, section 7 of the fvwm FAQ shows some real life applications of script
ing. Please refer to the sections COMMANDS FOR USER FUNC TIONS AND SHELL COMMANDS and CONDITIONAL COMMANDS for details. A word of warning: During execution of complex
functions, fvwm needs to take all input from the mouse
pointer (the pointer is "grabbed" in the slang of X). No
other programs can receive any input from the pointer
while a function is run. This can confuse some programs.
For example, the xwd program refuses to make screen shots
when run from a complex function. To achieve the same
functionality you can use the. Read or PipeRead command instead.

THE LIST OF FVWM COMMANDS

ArrayAddToFunc MakeMissingDirectoryMenu
+ I Exec fvwm_make_directory_menu.sh $0

ArrayNote 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.

ArrayIs used by fvwm with the SubmenusLeft option below.

VerticalItemSpacing and VerticalTitleSpacing con trol the vertical spacing of menu items and titles
like ItemFormat controls the horizontal spacing. Both take two numeric arguments that may range from
-100 to +100. The first is the gap in pixels above
a normal menu item (or a menu title), the second is
the gap in pixels below it. Negative numbers do
not make much sense and may screw up the menu com
pletely. If no arguments are given or the given
arguments are invalid, the built-in defaults are
used: one pixel above the item or title and two
below.

SubmenusLeft mirrors the menu layout and behavior. Sub-menus pop up to the left, the sub-menu triangle
is drawn left and the mini icon and side picture
are drawn at the right side of the menu. The
default is SubmenusRight. The position hints of a menu are also affected by this setting, i.e. posi
tion hints using item or menu as context rectangle and position hints using m offsets.

AutomaticHotkeys and AutomaticHotkeysOff control the menu's ability to automatically provide hotkeys on the first character of each menu item's
label. This behavior is always overridden if an
explicit hot-key is assigned in the AddToMenu com mand.

Arrayture True, Wait False
The option * refers to all available options.

The Read option also controls the PipeRead command.

The DynamicMenu option affects the DynamicPopu_ pAction and MissingSubmenuFunction options of the AddToMenu command. If this option is set to "False", then the busy cursor is not displayed dur
ing a dynamic menu command even if this command is
a Read or PipeRead command and the Read option is set to "True".

ArrayCursorStyle DESTROY 56
CursorStyle DESTROY gumby

Arraywhere "lang" depends on the locale. If no directory
is given the default directory path is assumed. If
no text domain is given, "fvwm" is assumed. Without
argument the default locale path is restored.

As for the ImagePath command, path may contain environment variables and a '+' for appending or
prepending locale path easily.

ArrayAddToFunc SwitchToWindow
+ I WindowListFunc

ArrayIf you use the Layer m [n] option, only windows in layers between m and n are displayed. n defaults to
m. With the ReverseOrder option the order of the windows in the list is reversed.

With the CurrentAtEnd option the currently focused window (if any) is shown at the bottom of the list.
This is mostly intended for simulating the Alt-Tab
behavior in another GUI.

IconifiedAtEnd makes iconified windows be moved to the end of the list. This is also from another
GUI.

The NoGeometry option causes fvwm to not display the geometries as well as the separators which
indicate the different desktops. NoGeometryWith_ Info removes the geometries, but keep the desktop
information and indicates iconic windows.
NoDeskNum causes fvwm to not display the desktop number in the geometry or before the window title
with the NoGeometryWithInfo option. NoNumInDeskTi_ tle is only useful if a desktop name is defined
with the DesktopName command. It causes fvwm to not display the desktop number before the desktop name.
By default, the WindowList menu have a title which
indicates the current desk or the selected desktop
if the Desk condition is used. The NoCurrentDesk_ Title option removes this title. TitleForAllDesks causes fvwm to add a menu title with the desk name
and/or number before each group of windows on the
same desk. With NoLayer, the layer of the window is not diplayed. The options ShowPage, ShowPageX and ShowPageY enable displaying the page of the window rounded multiples of the display size. With
ShowScreen, the window's Xinerama screen number is displayed.

The MaxLabelWidth option takes the number of char acters to print as its argument. No more than that
many characters of the window name are visible.

ArrayThis example starts the "QuitVerify" form if
you draw a box that begins in the top left
corner.

ArrayA Style command with the IconBox option
replaces any icon box previously defined for
the same style. Thats why the backslash in
the previous example is required.

Note: The geometry for the icon box command
takes the additional screen specifier "@w"
in case a Xinerama setup is used. This des
ignates the screen where the window center
is located. The additional screen specifier
is not allowed anywhere else.

If you never define an icon box, or you fill
all the icon boxes, fvwm has a default icon
box that covers the screen, it fills top to
bottom, then left to right, and has an 80x80
pixel grid. To disable all but the default
icon box you can use IconBox without argu
ments in a separate Style command. To dis
able all icon boxes including the default
icon box, the argument "none" can be speci
fied.

ArrayAll arguments are measured in pixels. When
all four arguments are passed to IconSize,
width and height represent the minimum size of an icon, and maxwidth and maxheight represent the maximum size of an icon. Icon
images that are smaller than the minimum
size are padded. Icon images that are big
ger than the maximum size are clipped.

If only two arguments are passed to Icon_
Size, width and height represent the abso lute size of an icon. Icons covered by this
style will be padded or clipped to achieve
the given size.

If no arguments are specified, the default
values are used for each dimension. This
effectively places no limits on the size of
an icon.

The value of "-1" can be used in place of
any of the arguments to specify the default
value for that dimension.

Note that application-provided icon windows
are not affected.

MiniIcon specifies a pixmap to use as the
miniature icon for the window. This minia
ture icon can be drawn in a title-bar button
(see ButtonStyle), and can be used by vari ous fvwm modules (FvwmWinList, FvwmIconMan and FvwmTaskBar). It takes the name of a pixmap as an argument.

WindowShadeShrinks and WindowShadeScrolls control if the contents of a window that is
being shaded with the WindowShade command are scrolled (default) or if they stay in
place. The shrinking mode is a bit faster

The WindowShadeSteps option selects the num ber of steps for animation when shading a
window with WindowShade. It takes one num ber as its argument. If the number has a
trailing 'p' it sets the number of pixels to
use as the step size instead of a fixed num
ber of steps. 0 disables the animation.
This happens too if the argument is omitted
or invalid.

The WindowShade command has two modes of operation: busy and lazy shading. Busy
shading can be 50% slower than lazy shading,
but the latter can look strange under some
conditions, for example, if the window bor
ders, buttons or the title are filled with a
tiled pixmap. Also, the window handles are
not drawn in lazy mode and the border relief
may only be draw partially right before the
window reaches the shaded state or tight
after leaves the unshaded state. By default,
fvwm uses lazy mode if there are no bad
visual effects (not counting the window han
dles) and busy mode otherwise. Use the Win_
dowShadeAlwaysLazy or WindowShadeBusy to force using the lazy or busy mode. The
default setting is restored with Window_
ShadeLazy.

ArrayNow, whenever a window is created and the
user presses button 3 to finish initial
placement, the window is automatically
enlarged until it hits the bottom screen
border.

Array-->

Style * MinOverlapPercentPlacement

Style * ActivePlacementsHonorsStartsOnPage
-->

Style * ManualPlacementsHonorsStartsOnPage

Style * ActivePlacementsHonorsStartsOnPageOff
-->

Style * ManualPlacementsHonorsStartsOnPageOff

Placement policy options and window stacking NoPPosition instructs fvwm to ignore the program specified position (PPosition hint)
when adding new windows. Using PPosition is
required for some applications, but if you
don't have one of those its a real headache.
Many programs set PPosition to something
obnoxious like 0,0 (upper left corner).

NoUSPosition works like NoPPosition but applies suppresses using the user specified
position indicated by the program (USPosi
tion hint). It is generally a bad thing to
override the user's choice, but some appli
cations misuse the USPosition hint to force
their windows to a certain spot on the
screen without the user's consent.

NoTransientPPosition and UseTransientPPosi_ tion work like NoPPosition and UsePPosition but apply only to transient windows.

NoIconPosition instructs fvwm to ignore the program specified icon position (IconPosi
tion hint) when iconifying the window.

StartsOnDesk takes a numeric argument which is the desktop number on which the window
should be initially placed. Note that stan
dard Xt programs can also specify this via a
resource (e.g. "-xrm '*Desk: 1'").

StartsOnPage takes 1, 2, or 3 numeric argu ments. If one or three arguments are given,
the first (or only) argument is the desktop
number. If three arguments are given, the
2nd and 3rd arguments identify the x,y page
position on the virtual window. If two
arguments are given, they specify the page
position, and indicate no desk preference.
If only one argument is given, StartsOnPage functions exactly like StartsOnDesk. For those standard Xt programs which understand
this usage, the starting desk/page can also
be specified via a resource (e.g., "-xrm
'*page: 1 0 2'"). StartsOnPage in conjunc tion with SkipMapping is a useful technique when you want to start an app on some other
page and continue with what you were doing,
rather than waiting for it to appear.

StartsOnScreen takes one argument. It can be 'p' for the primary screen, 'c' for the
current screen (containing the mouse
pointer), 'g' for the global screen or the
screen number itself (counting from zero).
A new window is placed on the specified Xin
erama screen. The default is to place win
dows on the screen that contains the mouse
pointer at the time the window is created.
However, those windows which are not placed
by fvwm (i.e., those with a USPosition hint
from a user specified geometry) are normally
placed in a position relative to the global
screen. The StartsOnScreen style is also useful to cause these windows to be placed
relative to a specific Xinerama screen. For
example:

Style * StartsOnScreen c

Would cause all windows, including those
with their own geometry to be placed rela
tive to the current Xinerama screen rather
than the global screen. For those standard
Xt programs which understand this usage, the
starting desk/page can also be specified via
a resource (e.g., "-xrm '*fvwmscreen: c'").
('fvwmscreen' was chosen because some appli
cations already use ´.screen' for other pur
poses.)

StartsOnPageIncludesTransients causes the StartsOnPage style to be applied even for transient windows. This is not usually use
ful, since transients are usually pop ups
that you want to appear in your visible
viewport; but occasionally an application
uses a transient for something like a
startup window that needs to be coerced into
place.

ManualPlacementIgnoresStartsOnPage sup presses StartsOnPage or StartsOnDesk place ment in the event that both ManualPlacement and SkipMapping are in effect when a window is created. This prevents you from interac
tively placing a window and then wondering
where it disappeared to, because it got
placed on a different desk or page. Manu_
alPlacementHonorsStartsOnPage allows this to happen anyway. The option has no effect if
SkipMapping is not in effect, because fvwm switches to the proper desk/page to perform
interactive placement. The default is Manu_
alPlacementIgnoresStartsOnPage; ManualPlace_ mentHonorsStartsOnPage matches the way the old StartsOnDesk style used to handle the situation.

CaptureHonorsStartsOnPage causes the initial capture (of an already existing window) at
startup to place the window according to the
StartsOnPage and StartsOnScreen desk, page and Xinerama screen specification. Cap_
tureIgnoresStartsOnPage causes fvwm to ignore these settings (including StartsOn_
Desk) on initial capture. The default is
CaptureIgnoresStartsOnPage.

RecaptureHonorsStartsOnPage causes a window to be placed according to, or revert to, the
StartsOnPage and StartsOnScreen desk, page and Xinerama screen specification on Restart
or Recapture. RecaptureIgnoresStartsOnPage causes fvwm to respect the current window
position on Restart or Recapture. The default is RecaptureIgnoresStartsOnPage.

Layer accepts one optional argument: a nonnegative integer. This is the layer the
window is put in. If no argument is given,
any previously set value is deleted and the
default layer is implied.

StaysOnTop puts the window in the top layer. This layer can be changed by the command
DefaultLayers; the default is 6.

StaysPut puts the window in the put layer.
This layer can be changed by the command
DefaultLayers; the default is 4.

StaysOnBottom puts the window in the bottom layer. This layer can be changed by the
command DefaultLayers; the default is 2.

StartsLowered instructs fvwm to put the win dow initially at the bottom of its layer
rather than the default StartsRaised.

SkipMapping tells fvwm not to switch to the desk the window is on when it gets mapped
initially (useful with StartsOnDesk or StartsOnPage).

KeepWindowGroupsOnDesk makes new windows that have the window group hint set appear
on the same desk as the other windows of the
same group. Since this behavior may be con
fusing, the default setting is ScatterWin_ dowGroups. The window group hint is ignored
when placing windows in this case.

Transient windows
DecorateTransient causes transient windows, which are normally left undecorated, to be
given the usual fvwm decorations (title bar,
buttons, etc.). Note that some pop-up win
dows, such as the xterm menus, are not man
aged by the window manager and still do not
receive decorations. NakedTransient (the default) causes transient windows not to be
given the standard decorations. You can only
bind keys or mouse buttons to the sides and
the client window of an undecorated window
('S' and ´W' contexts in bindings, see Mouse
and Key commands).

A window with the RaiseTransient style that has transient windows raises all its tran
sients when it is raised. The DontRaise_
Transient style disables this behavior. All
windows are then treated as if they had no
transients.

A window with the LowerTransient style that has transient windows lowers all its tran
sients when it is lowered. The DontLower_
Transient style disables this behavior. All
windows are then treated as if they had no
transients.

The StackTransientParent style augments RaiseTransient and LowerTransient styles. Raising a window with StackTransientParent style transfers the raise action to the main
window if the window being raised is a tran
sient and its main window has RaiseTransient style; this effect makes raise on a tran
sient act just like raise on its main - the
whole group is raised. Similar behavior
holds for lowering a whole group of
transients when the main has LowerTransient style. DontStackTransientParent turns this behavior off. (Dont)StackTransientParent has no effect if RaiseTransient and Lower_ Transient are not used.

A reasonable emulation of Motif raise/lower
on transients is possible like this

Style * RaiseTransient
Style * LowerTransient
Style * StackTransientParent

Extended Window Manager Hints styles To understand the used terminology in this
sub section, please read the section
EXTENDED WINDOW MANAGER HINTS.

EWMHDonateIcon instructs fvwm to set the application ewmh icon hint with the icon
that is used by fvwm if the application does
not provide such hint (and if the icon used
by fvwm is not an icon window). EWMHDo_
nateMiniIcon does the same thing for mini icons. This allows compliant pager, taskbar,
iconbox ...etc to display the same (mini)
icons as fvwm. Note that on some hardware
(e.g., 8-bit displays) these styles can slow
down window mapping and that in general only
one of these styles is needed by a compliant
application. EWMHDontDonateIcon and EWMH_ DontDonateMiniIcon restore the defaults which are to not set any ewmh (mini) icons
hints.

By default, if an application provides an
ewmh icon hint of small size (i.e., height
and width less than or equal to 22), then
fvwm uses this icon as its mini icon. EWMH_
MiniIconOverride instructs fvwm to ignore ewmh icons and to use the mini icon provided
by the MiniIcon style. EWMHNoMiniIconOver_ ride restores the default.

EWMHUseStackingOrderHints causes fvwm to use EWMH hints which change the window layer
(such a hint is used by KDE and is not stan
dard). EWMHIgnoreStackingOrderHints causes fvwm to ignore such hints.

An application can ask for some reserved
space on the desktop by a hint. In the EWMH
terminology such a hint is called a strut
and it is used to compute the working area
and may be used for window placement and in
the maximize command. EWMHIgnoreStrutHints causes fvwm to ignore such hints, as
EWMHUseStrutHints, causes fvwm to use it which is the default.

EWMHIgnoreStateHints causes fvwm to ignore initial EWMH state hints when a new window
is mapped. The default EWMHUseStateHints causes fvwm to accept such hints.

EWMHMaximizeIgnoreWorkingArea causes fvwm to ignore the EWMH working area when it exe
cutes a Maximize command. With EWMHMaxi_ mizeUseWorkingArea the EWMH working area is used as with EWMHMaximizeUseDynamic_ WorkingArea the EWMH dynamic working area is used (the default).

EWMHPlacementIgnoreWorkingArea causes fvwm to ignore the EWMH working area when it
places (or places again) a window. With
EWMHPlacementUseWorkingArea the EWMH working area is taken in account as with EWMHPlace_
mentUseDynamicWorkingArea the EWMH dynamic working area is taken in account (the
default). Note that with the MinOverlap_ Placement and MinOverlapPercentPlacement placement policy, the way the EWMH (dynamic)
working area is taken in account is config
urable with the MinOverlapPlacementPenalties style.

Miscellaneous
The BackingStore, BackingStoreOff and Back_ ingStoreWindowDefault determine if the X server uses backing storefor the window or
not. BackingStore means that the X server tries to keep the obscured parts of a window
in memory. This is usually slower if the
client runs on the same machine as the X
server, but can be much faster if the con
nection is slow (see also SaveUnder below).
BackingStoreOff tells disables backing store for the window. By default, fvwm does not
enable or disable backing store itself but
leaves is as the window requested it. To
revert back to the application's choice, use
the BackingStoreWindowDefault style.

Note: This style is useless if the X server
does not allow backing store.

SaveUnder enables the corresponding window
attribute in the X server. For a window
using this style, the X server tries to
store the graphics below it in memory which
is usually slower if the client runs on the
same machine as the X server. SaveUnder may
speed up fvwm if the connection to the X
server is slow (e.g. over a modem link). To
disable back

FVWM 30 May 2003 FVWM(1)