man fvwm Command

Man page for apt-get fvwm Command

Man Page for fvwm in Linux

Ubuntu Man Command : man fvwm

Man Fvwm  Command

This tutorial shows the man page for man fvwm in linux.

Open terminal with 'su' access and type the command as shown below:
man fvwm

Result of the Command Execution shown below:

FVWM(1)                                                                      Fvwm 2.5.28                                                                     FVWM(1)

Fvwm F? Virtual Window Manager for X11

fvwm [ c config command] [ d displayname] [ f config file] [ r] [ s [screen_num]] [ V] [ C visual class | I visual id] [ l colors [ L] [ A] [ S] [ P]] [ D]
[ h] [ i client id] [ F state file] [ debug stack ring] [ blackout]

Fvwm is a window manager for X11. It is designed to minimize 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 patched
version of 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 achieved 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 unrelated 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 keyboard shortcuts.

Fvwm has also overcome the distinction between configuration commands and action commands that most window managers make. Configuration commands typically
set fonts, colors, menu contents, key and mouse function bindings, while action commands do things like raise and lower windows. Fvwm makes no such
distinction, and allows 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 separately 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, moving the pointer
over a NeverFocus decoration window does not deprive the terminal of focus.

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

i | clientid id
This option is used when fvwm is started by a session manager. Should not be used by a user.

c | cmd config command
Causes fvwm to use config command instead of 'Read config' (or 'Read .fvwm2rc') as its initialization command. (Note that up to 10 f and c parameters
can be given, and they are executed in the order specified.)

Any module started by command line arguments is assumed to be a module that sends back config commands. All command line modules have to quit before
fvwm proceeds on to the StartFunction and setting border decorations and styles. There is a potential deadlock if you start a module other than
FvwmCpp/FvwmM4/FvwmPerl but there is a timeout so fvwm eventually gets going.

As an example, starting the pager this way hangs fvwm until the timeout, but the following should work well:

fvwm c "AddToFunc StartFunction I Module FvwmPager"

d | display displayname
Manage the display called displayname instead of the name obtained from the environment variable $DISPLAY.

D | debug
Puts X transactions in synchronous mode, which dramatically slows things down, but guarantees that fvwm's internal error messages are correct. Also
causes fvwm to output debug messages while running.

f config file
Causes fvwm to read config file instead of ~/.fvwm/config as its initialization file. This is equivalent to c 'Read config file'.

h | help
A short usage description is printed.

r | replace
Try to take over from a previously running wm. This does not work unless the other wm is ICCCM2 2.0 compliant.

F | restore state file
This option is used when fvwm is started by a session manager. Should not be used by a user.

s | single screen [screen_num]
On a multi screen display, run fvwm only on the screen named in the $DISPLAY environment variable or provided through the d option. The optional
argument screen_num should be positive or null and override the screen number. Normally, fvwm attempts to start up on all screens of a multi screen

V | version
Prints the version of fvwm to stderr. Also prints an information about the compiled in support for readline, rplay, stroke, xpm, png, svg, GNOME hints,
EWMH hints, session management, bidirectional text, multibyte characters, xinerama and Xft aa font rendering.

C | visual visual class
Causes fvwm to use visual class for the window borders and menus. visual class can be "StaticGray", "GrayScale", "StaticColor", "PseudoColor",
"TrueColor" or "DirectColor".

I | visualid id
Causes fvwm to use id as the visual id for the window 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.

l | color limit limit
Specifies a limit on the colors used in image, gradient and possibly simple colors used by fvwm. In fact, fvwm (and all the modules) uses a palette with
at most limit colors. This option is only useful with screens that display 256 colors (or less) with a dynamic visual (PseudoColor, GrayScale or
DirectColor). The default depends on your X server and how you run fvwm. In most case this default is reasonable. The l option should be used only if
you encounter problems with colors. By default, fvwm tries to detect large pre allocated palettes. If such a palette is detected fvwm uses it and a
priori the l must not be used. Moreover, in this case the A and S options are forced. Note that XFree 4.2 pre allocates 244 colors (if you use a
driver with Render support) leaving only a few free colors. This may lead to some color problems (and nothing can be done). XFree 4.3 or better
pre allocate only 85 colors. If no pre allocated palette is auto detected the defaults are as follow:

Display depth 8 (256 colors)

PseudoColor: 68 (4x4x4 color cube + 4 grey)
GrayScale: 64 regular grey
DirectColor: 32 (3x3x3 color cube + 5 grey)

Display depth 4 (16 colors)

PseudoColor: 10 (2x2x2 color cube + 2 grey)
GrayScale: 8 regular grey
DirectColor: 10 (2x2x2 color cube + 2 grey)

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 other
defaults are used.

Now what to do if you encounter problems with colors? 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 application needs read write colors). What it should be understand is that you have only 256 colors and that all
the applications which use 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 may have no more free colors and some applications (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 particular 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 or 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
ColormapFocus command for a better control of the color maps switching). The second method is to limit the number of colors that the applications use.
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 cube 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 definitive 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 configuration 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 number of times fvwm has allocated the colors).

L | strict color limit
If the screen displays 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. Moreover, 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 applications and images 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 allocate all the colors of its palette at start up for
reserving these colors for future use. This option forces the 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

This option is provided for backward compatibility only. Blacking out the screen during startup is not necessary (and doesn't work) anymore. This
option will be removed in the future.

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

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 operation 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 borders. Similarly for the window title.

Up to ten title bar buttons may exist. Their use is completely 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 configuration 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 Mouse command.

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 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 stacking order; a window in a lower layer never obscures a window 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

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 xbiffs, so you only need to run one such gadget and it always stays with you. Icons can also be made to stick to the glass, if

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 visible 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 window'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 coordinates larger than the physical screen size), however, suffers 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 your config 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 command 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 applications understand the use of these
options, however. You could achieve the same results with the following lines in your .Xdefaults file:

XTerm*Desk: 1


XTerm*Page: 3 2 1

If the s command line argument is not given, fvwm automatically starts up on every screen on the specified display. After fvwm starts each screen is
treated independently. 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 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 EdgeResistance option of the
Style command 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 disabled on the fly or from the configuration file with the Xinerama command. Many modules and commands work nicely with Xinerama

Whenever 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 rectangle 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 configuration file that would work on a single screen. It may not perform very well if
the involved screens use different screen resolutions. In this situation, windows may get stuck in the portion of the whole desktop that belongs to neither
screen. When this happens, the windows or icons can be retrieved with the command

All MoveToScreen

that can be entered in an FvwmConsole window or with FvwmCommand.

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 XineramaSlsScreens are used to
configure this feature.

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 config

This looks for file config in $FVWM_USERDIR and $FVWM_DATADIR directories, as described in Read. If this fails more files are queried for backward
compatibility. Here is the complete list of all file locations queried in the default installation (only the first found file is used):



Please note, the last 5 locations are not guaranteed to be supported in the future.

If a configuration file is not found, the left mouse button, or Help or F1 keys on the root window bring 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 display on which fvwm is running. $DISPLAY
may be unix:0.0 or :0.0, which doesn't work too well when passed through ssh to another machine, so $HOSTDISPLAY is set to a network 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


Module FvwmXxx

into your config, but it is not recommended; do this only if you know what you are doing. It is usually important to start applications or modules after the
entire config 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 function (usually StartFunction or InitFunction).
This way they are only started after fvwm finishes to read and execute config file.

Fvwm has three special functions for initialization: StartFunction, which is executed on startups and restarts; InitFunction and RestartFunction, which are
executed during initialization and restarts (respectively) just after StartFunction. These functions may be customized in a user's config file using 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, executed 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 SessionInitFunction and SessionRestartFunction are executed instead of InitFunction and RestartFunction.
This helps to define the user's config 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 Module FvwmPager * *
+ I Module FvwmButtons

DestroyFunc InitFunction
AddToFunc InitFunction
+ I Module FvwmBanner
+ I Module FvwmTaskBar
+ I Exec 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 do not need to define all special functions if some are empty. Also note, all these special functions may be emulated now using StartFunction and
ExitFunction, like this:

DestroyFunc StartFunction
AddToFunc StartFunction
+ I Test (Init) Module FvwmBanner
+ I Module FvwmPager * *
+ I Test (Restart) Beep

DestroyFunc ExitFunction
AddToFunc ExitFunction
+ I Test (Quit) Echo Bye bye
+ I KillModule MyBuggyModule
+ I Test (ToRestart) Beep

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 generated during compilation.

Fvwm can load .xbm, .xpm, .png and .svg images. XBM images are monochrome. Fvwm can always display XBM files. XPM and PNG formats are color images. SVG
is a vector graphics image format. Compile time options determine whether fvwm can display XPM, PNG or SVG icons and images. See the INSTALL.fvwm file for
more information.

The related SHAPE compile time option can make fvwm display spiffy shaped icons.

SVG rendering options
SVG images are generated from (XML) text files. A really simple SVG file might look something like this:

By default, SVG images are rendered as the image creator intended them to. But since SVG is a vector graphics format, the images can be rendered at any
choosen size and rotation, e.g. making it possible to use the same icon file rendered at diffrent sizes for the Icon and MiniIcon styles.

The rendering options are specified as a string appended to the SVG filename as follows:

image.svg:[!] [(1) size] [(2) position] [(3) rotation] [(4) scale] ...

(1) [ ]width{x}[ ]height
(2) { | +}xpos{ | +}ypos
(3) @[ ]angle
(4) {* | /}[ ]factor[x | y]

The option string always starts with a colon (':') to separate it from the filename. An empty option string can skip this colon, but it might still be a
good idea to include it to prevent ambiguity if the filename contains any colon.


An exclamation point ('!') transposes the entire final image (including the rendering area), i.e. all the horizontal and all the vertical coordinates are
swapped with each other.


width and height specifies the dimensions of the rendering area in pixels, i.e. the dimensions of the resulting image. The actual image is fitted to fill
the entire rendering area.


Use a width or height value of 0 to keep the aspect ratio.


A ' ' before width mirrors the rendering area horizontally.

image.svg: 0x0

A ' ' before height mirrors the rendering area vertically.

image.svg:0x 0

xpos and ypos specifies a translation of the image in pixels. A positive xpos value moves the image to the right. A positive ypos value moves it down.
Moving it partially outside of the rendering area results in a cropped image.

image.svg: 30 0
image.svg: 0+10
image.svg: 30+10

angle specifies a rotation around the actual image center in degrees. This might result in a cropped image. A positive value rotates the image clockwise.
Floating point values are recognized.

image.svg:@ 90

factor specifes a scaling of the actual image (not the rendering area). Scaling it up results in a cropped image. Floting point values are recognized.
Division by zero is ignored. If factor is directly followed by a 'x' or a 'y', the scaling is horizontal or vertical respectively. Otherwise the scaling is


Scaling down a translated or rotated image can prevent cropping.


Repeated usage of translation, rotation, and scaling is allowed. Translation and rotation are additive. Scaling is multiplicative.


When combining affine transformations, the scaling is always done first, then the rotation, and finally the translation.

image.svg: 30+10@30/3x/2y

Use a negative scale factor to mirror the actual image.

image.svg: 30+10@30/ 3x/2y

Mirroring of the rendering area is done after any scaling, rotation or translation of the image.

image.svg: 0x0 30+10@30/3x/2y

Transposing is done last of all, after everything else.

image.svg:! 0x0 30+10@30/3x/2y

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

Related Topics

Apt Get Commands