Fvwm - F? Virtual Window Manager for X11

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:

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

Window geometries are specified relative to the current viewport. That is:

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:

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:

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:

starts an xterm on desk number 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:

or

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

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

or

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.

11.1. SVG rendering options

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

<svg width="120" height="80">
	<rect fill="red"     width="40" height="40"  x="0"   y="0"  />
	<rect fill="lime"    width="40" height="40"  x="40"  y="0"  />
	<rect fill="blue"    width="40" height="40"  x="80"  y="0"  />
	<rect fill="cyan"    width="40" height="40"  x="0"   y="40" />
	<rect fill="magenta" width="40" height="40"  x="40"  y="40" />
	<rect fill="yellow"  width="40" height="40"  x="80"  y="40" />
</svg>

image.svg

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.

filename_without_colon.svg
filename:with:colon.svg:

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.

image.svg:!

image.svg:!

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.

image.svg:60x60

image.svg:60x60

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

image.svg:0x60
image.svg:60x0

image.svg:0x60

image.svg:60x0

A '-' before width mirrors the rendering area horizontally.

image.svg:-0x0

A '-' before height mirrors the rendering area vertically.

image.svg:0x-0

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

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:@180
image.svg:@-90
image.svg:@30
image.svg:@57.3

image.svg:@30

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

image.svg:*2
image.svg:/2
image.svg:/3x
image.svg:/2y

image.svg:*2

image.svg:/2

image.svg:/2y

Scaling down a translated or rotated image can prevent cropping.

image.svg:@30*0.6

image.svg:@30*0.6

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

image.svg:*2/3
image.svg:/3x/2y

image.svg:/3x/2y

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

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

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

Use a negative scale factor to mirror the actual image.

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

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

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

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 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 by 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 simultaneously executing modules is limited by the operating system'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 config setup file. Certain auxiliary information is also transmitted, as in the sample module FvwmButtons.

Please refer to the Module Commands section for details.

Fvwm attempts to be ICCCM 2.0 compliant. Check http://tronche.com/gui/x/icccm/ for more info. 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 window). The same problem exists with mouse bindings.

The ICCCM states that windows possessing the property

should not be given the keyboard input focus by the window manager. These windows can take the input focus by themselves, however. A number of applications set this property, 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

resembles the Restart command. It is not exactly the same, since killing the previously running wm may terminate 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 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 user's 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

Fvwm attempts to be GNOME (version 1) compliant. Check http://www.gnome.org for what that may mean. To disable GNOME hints for some or all windows, the GNOMEIgnoreHints style can be used.

Fvwm attempts to respect the extended window manager hints (ewmh or EWMH for short) specification: http://www.freedesktop.org/wiki/Standards_2fwm_2dspec 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 application based on GTK+ version 2). Applications which respect this specification are called ewmh compliant applications.

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 applications (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 function. 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 window.

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 EwmhBaseStruts command.

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.

Fvwm supports all the Open Look decoration hints (except pushpins). Should you use any such application, please add the following line to your config:

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 NeverFocus focus policy and the Lenience style for all such applications (the windows still get the focus):

Style <application name> NeverFocus, Lenience

But in case you can not live with that focus policy, you can try using one of the other focus policies in combination with the Lenience style:

Style <application name> MouseFocus, Lenience
Style <application name> SloppyFocus, Lenience
Style <application name> ClickToFocus, Lenience

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 ~/.fvwm/config file (if it appears at all), and start fvwm with the command

Cpp is the C-language pre-processor. fvwm offers cpp processing which mirrors the m4 pre-processing. To find out about it, re-read the M4 section, but replace "m4" with "cpp".

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.

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 movement controls ( n, p, f, b, and j, k, h, l ) can be used instead of the arrow keys.

Fvwm supports session management according to the X Session Management Protocol. It saves and restores window position, size, stacking order, desk, stickiness, shadiness, maximizedness, iconifiedness for all windows. Furthermore, some global state is saved.

Fvwm doesn't save any information regarding styles, decors, functions or menus. If you change any of 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 following anomaly when used on a multi-screen display: Starting 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 session 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.

A number of commands take one or several boolean arguments. 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 commands allow "toggle" too which means that the feature is disabled if it is currently enabled and vice versa.

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 creates. This is primarily for new users that have not created 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 -

Quotes are required only when needed to make fvwm consider two or more words to be a single argument. Unnecessary quoting is allowed. If you want a quote character in your text, you must escape it by using the backslash character. For example, if you have a pop-up menu called "Window-Ops", then you do not 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.

Whenever an 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 quoting. To get a literal '$' use "$$".

If a command is prefixed with a '-' parameter expansion isn't performed. This applies to the command immediately following the '-', in which the expansion normally would have taken place. When uesed together with other prefix commands it must be added before the other prefix.

Example:

Pick -Exec exec xmessage '$[w.name]'

opens an xmessage dialog with "$[w.name]" unexpanded.

The longer variables may contain additional variables inside the name, which are expanded before the outer variable.

In earlier versions of fvwm, some single letter variables were supported. It is deprecated now, since they cause a number of problems. You should use the longer substitutes instead.

Example:

# Print the current desk number, horizontal page number
# and the window's class (unexpanded here, no window).
Echo $[desk.n] $[page.nx] $[w.class]

Note: If the command is called outside a window context, it prints "$[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:

Some examples can be found in the description of the AddToFunc command.

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 scripting. Please refer to the sections User Functions 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 command descriptions below are grouped together in the following sections. The sections are hopefully sorted in order of usefulness to the newcomer.