Provided by: fvwm3_1.0.6a+ds-1build1_amd64 bug

NAME

       fvwm3 - F? Virtual Window Manager for X11

SYNOPSIS

       fvwm3 [-c config-command] [-d displayname] [-f config-file] [-o logfile] [-s [screen_num]]
       [-v]

DESCRIPTION

       Fvwm is a window manager for X11 optimised for speed.

       Fvwm is intended to have a small memory footprint and is extremely customizable and
       extendible. A large virtual desktop and multiple disjoint desktops can be used separately
       or together. The virtual desktop pretends that the video screen is really quite large, and
       you can scroll around within the desktop. The multiple disjoint desktops pretend there are
       really several screens to work at, but each screen is completely unrelated to the others.

       Fvwm provides keyboard accelerators that allow one to perform practically all window
       manager functions, including moving and resizing windows and operating the menus, using
       keyboard shortcuts.

       Fvwm does not distinguish between configuration and action commands. Configuration
       commands typically set fonts, colors, menu contents, and key and mouse function bindings,
       while action commands do things like raising and lowering windows. Fvwm makes no such
       distinction and allows anything to be changed at any time.

OPTIONS

       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.

       -f config-file
           Causes fvwm to read config-file instead of ~/.fvwm/config as its initialization file.
           $FVWM_USERDIR can also be used to change location of default user directory ~/.fvwm.

       -o logfile
           Write log messages to logfile. If logfile is '-', log to the console. (Does not turn
           on logging, see the -v option.)

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

       -V | --version
           Prints the version of fvwm to stderr. Also prints an information about the compiled in
           features as stated at compiletime.

       -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)

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

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

       -v | --verbose
           Enables debug logging. Writes in append mode to fvwm log file, which is
           ~/.fvwm/fvwm3-output.log by default. See ENVIRONMENT section on how to override this
           location on fvwm3 startup using $FVWM_USERDIR or $FVWM3_LOGFILE .

           Logging can also be dynamically toggled on and off using signals:

               SIGUSR1 : used as a signal to restart Fvwm
               SIGUSR2 : used as a signal to toggle opening/closing debug log file

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

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 using the WindowList command or the FvwmIconMan 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:

           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

       or

           XTerm*Page: 3 2 1

USE ON MULTI-SCREEN DISPLAYS

       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 RandR support.

RANDR SUPPORT

       Fvwm supports the RandR X11 protocol. If Fvwm has been compiled wiith RandR support then
       it tracks the outputs (displays) which it finds. These outputs are stored by name, which
       can be found by running using the xrand(1) command.

       In doing so, Fvwm tracks events from RandR, such as when a given output changes size, or
       has been removed. In such cases, Fvwm will react by moving windows. If an output is
       removed, those windows on that removed output will be moved to the next active output (the
       output which contains the mouse pointer). If the same output reappears, Fvwm will move
       those windows back again.

       In addition to specific FvwmEvent conditions which can be used to track a monitor’s
       change, there is a function called RandRFunc which the user can define to be run when a
       screen event occurs (such as enabling/disabling/resolution change):

           DestroyFunc RandRFunc
           AddToFunc   RandRFunc
           + I Exec exec xmessage "A screen changed"

DESKTOP BEHAVIOUR

       Because Fvwm has the capability to track outputs, Fvwm can be told how to handle those.
       This is controlled via the DesktopConfiguration command. By default, Fvwm treats all
       outputs it finds as one large screen, although Fvwm can be told to treat screens
       indepedantly of each other.

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 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):

           $HOME/.fvwm/config
           /usr/local/share/fvwm/config

           $HOME/.fvwm/.fvwm2rc
           $HOME/.fvwm2rc
           /usr/local/share/fvwm/.fvwm2rc
           /usr/local/share/fvwm/system.fvwm2rc
           /etc/system.fvwm2rc

       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

       or

       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 FvwmIconMan
            + I Exec xsetroot -solid cyan
            + I Exec xterm
            + I Exec netscape

           DestroyFunc RestartFunction
           AddToFunc RestartFunction
            + I Module FvwmIconMan

           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

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

ICONS AND IMAGES

       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:

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

       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 chosen size and rotation,
       e.g. making it possible to use the same icon file rendered at different 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_] ...

           {empty}(1) [-]_width_{x}[-]_height_

           {empty}(2) {- | +}_xpos_{- | +}_ypos_

           {empty}(3) @[-]_angle_

           {empty}(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:!

       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

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

           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

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

       factor specifes a scaling of the actual image (not the rendering area). Scaling it up
       results in a cropped image. Floating 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

       Scaling down a translated or rotated image can prevent cropping.

           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

       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

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

ICCCM COMPLIANCE

       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

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

           fvwm; vi ~/.fvwm/config; fvwm -replace

       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 !raise 5p 5p
           AddToFunc UrgencyDoneFunc
            + I Nop

EXTENDED WINDOW MANAGER HINTS

       Fvwm attempts to respect the extended window manager hints (ewmh or EWMH for short)
       specification: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html and some
       extensions of this specification.

       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 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 with RandR). 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.

CONFIGURATION

   Configuration Files
       The configuration file is used to describe mouse and button bindings, colors, the virtual
       display size, and related items. The initialization configuration file is typically called
       config (or .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 configuration 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, is supplied with the fvwm distribution. It is well commented
       and can be used as a source of examples for fvwm configuration. It may be copied from
       /usr/local/share/fvwm/config file.

       Alternatively, the built-in menu (accessible when no configuration file is found) has
       options to create an initial config file for the user.

FONTS

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

       First, you can use what we can call a usual font name, for example,

           -adobe-courier-bold-r-normal--10-100-75-75-m-60-ISO8859-1
           -adobe-courier-bold-r-normal--10-*
           -*-fixed-medium-o-normal--14-*-ISO8859-15

       That is, you can use an X Logical Font Description (XLFD for short). Then the "first" font
       which matches the description is loaded and used. This "first" font depends of your font
       path and also of your locale. Fonts which match the locale charset are loaded in priority
       order. For example with

           -adobe-courier-bold-r-normal--10-*

       if the locale charset is ISO8859-1, then fvwm tries to load a font which matches

           -adobe-courier-bold-r-normal--10-*-ISO8859-1

       with the locale charset ISO8859-15 fvwm tries to load

           -adobe-courier-bold-r-normal--10-*-ISO8859-15.

       A font name can be given as an extended XLFD. This is a comma separated list of (simple)
       XLFD font names, for example:

           -adobe-courier-bold-r-normal--14-*,-*-courier-medium-r-normal--14-*

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

       If you have Xft support you can specify an Xft font name (description) of a true type (or
       Type1) font prefixed by "xft:", for example:

           "xft:Luxi Mono"
           "xft:Luxi Mono:Medium:Roman:size=14:encoding=iso8859-1"

       The "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 example 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 possibilities: 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 parameter 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 subpixel 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)).

       After an Xft font name you can add after a ";" an XLFD font name (simple or extended) as:

           xft:Verdana:pixelsize=14;-adobe-courier-bold-r-normal--14-*

       then, if either loading the Xft font fails or fvwm has no Xft support, fvwm loads the font
       "-adobe-courier-bold-r-normal—14-*". This allows for writing portable configuration 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 encoding, (ii) the encoding of the loaded font is the locale
       encoding, and then (iii) the strings in the fvwm configuration files should use the locale
       encoding as well as the window and icon name. With Xft the situation is bit different 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.

       To override the previous rules, it is possible to specify the string encoding in the
       beginning of a font description as follow:

           StringEncoding=enc:_full_font_name_

       where enc is an encoding supported by fvwm (usually font name charset plus some unicode
       encodings: UTF-8, USC-2, USC-4 and UTF-16).

       For example, you may use an iso8859-1 locale charset and have an FvwmForm in Russian using
       koi8-r encoding. In this case, you just have to ask FvwmForm to load a koi8-r font by
       specifying the encoding in the font name. With a multibyte language, (as multibyte font
       works well only if the locale encoding is the charset of the font), you should use an
       iso10646-1 font:

           StringEncoding=jisx0208.1983-0:-*-fixed-medium-r-*-ja-*-iso10646-1

       or

           "StringEncoding=jisx0208.1983-0:xft:Bitstream Cyberbit"

       if your FvwmForm configuration uses jisx0208.1983-0 encoding. Another possibility is to
       use UTF-8 encoding for your FvwmForm configuration and use an iso10646-1 font:

           -*-fixed-medium-r-*-ja-*-iso10646-1

       or

           "StringEncoding=UTF-8:xft:Bitstream Cyberbit"

       or equivalently

           "xft:Bitstream Cyberbit:encoding=iso10646-1"

       In general iso10646-1 fonts together with UTF-8 string encoding allows the display of any
       characters in a given menu, FvwmForm etc.

       More and more, unicode is used and text files use UTF-8 encoding. However, in practice the
       characters used range over your locale charset. For saving memory (an iso10646-1 font may
       have a very large number of characters) or because you have a pretty font without an
       iso10646-1 charset, you can specify the string encoding to be UTF-8 and use a font in the
       locale charset:

           StringEncoding=UTF-8:-*-pretty_font-*-12-*

       In most cases, fvwm correctly determines the encoding of the font. However, some fonts do
       not end with valid encoding names. When the font name isn’t normal, for example:

           -misc-fixed-*--20-*-my_utf8-36

       you need to add the encoding after the font name using a slash as a delimiter. For
       example:

           MenuStyle * Font -misc-fixed-*--20-*-my_utf8-36/iso10646-1

       If fvwm finds an encoding, fvwm uses the iconv system functions to do conversion between
       encodings. Unfortunately, there are no standards. For conversion between iso8859-1 and
       UTF-8: a GNU system uses "ISO-8859-1" and other systems use "iso881" to define the
       converters (these two names are supported by fvwm). Moreover, in some cases it may be
       necessary to use machine specific converters. So, if you experience problems you can try
       to get information on your iconv implementation ("man iconv" may help) and put the name
       which defines the converter between the font encoding and UTF-8 at the end of the font
       name after the encoding hint and a / (another possible solution is to use GNU libiconv).
       For example use:

           Style * Font -misc-fixed-*--14-*-iso8859-1/*/latin1

       to use latin1 for defining the converter for the iso8859-1 encoding. The "*" in between
       the "/" says to fvwm to determine the encoding from the end of the font name. Use:

           Style * Font \
           -misc-fixed-*--14-*-local8859-6/iso8859-6/local_iso8859_6_iconv

       to force fvwm to use the font with iso8859-6 as the encoding (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, v

       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 Colorset 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 movement controls can be used instead of the arrow keys.

SESSION MANAGEMENT

       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.

BOOLEAN ARGUMENTS

       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.

BUILTIN 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 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 Alt key (same as the 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 -

COMMAND EXECUTION

   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 config 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
       execute 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, Colorset, 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 "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.

COMMAND EXPANSION

       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:

       $$
           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 function (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 function. This includes parameters that
           follow after "$9".

       $[n]
           The n:th positional parameter given to a complex function, counting from 0. If the
           corresponding parameter is undefined, the "$[n]" is deleted from the command line. The
           parameter is expanded unquoted.

       $[n-m]
           The positional parameters given to a complex function, starting with parameter n and
           ending with parameter m. If all the corresponding parameters are undefined, the
           "$[...]" is deleted from the command line. If only some of the parameters are defined,
           all defined parameters are expanded, and the remaining silently ignored. All
           parameters are expanded unquoted.

       $[n-]
           All the positional parameters given to a complex function, starting with parameter n.
           If all the corresponding parameters are undefined, the "$[...]" is deleted from the
           command line. All parameters are expanded unquoted.

       $[*]
           All the positional parameters given to a complex function. This is equivalent of
           $[0-].

       $[version.num]
           The version number, like "2.6.0".

       $[version.info]
           The version info, which contains the SHA of the latest commit (if compiled from git),
           or "(relesaed)" if a compiled from a release tarball.

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

       $[wa.x] $[wa.y] $[wa.width] $[wa.height]
           Either coordinate or the width or height of the EWMH working area.

       $[dwa.x] $[dwa.y] $[dwa.width] $[dwa.height]
           Either coordinate or the width or height of the dynamic EWMH working area.

       $[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 DesktopName 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, starting 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] $[w.visiblename] $[w.iconfile]
       $[w.miniiconfile] $[w.iconfile.svgopts] $[w.miniiconfile.svgopts]
           The window’s name, icon name, resource class and resource name, visible name, file
           name of its icon or mini icon defined with the Icon or MiniIcon style (including the
           full path if the file was found on disk), and (if fvwm is compiled with SVG support)
           the icon or mini icon svg rendering options (including the leading colon), or
           unexpanded "$[w.<attribute>]" string if no window is associated with the command.

           Note, the first 5 variables may include any kind of characters, so these variables are
           quoted. It means that the value is surrounded by single quote characters and any
           contained single quote is prefixed with a backslash. This guarantees that commands
           like:

               Style $[w.resource] Icon norm/network.png

           work correctly, regardless of any special symbols the value may contain, like spaces
           and different kinds of quotes.

           In the case of the window’s visible name, this is the value returned from the literal
           title of the window shown in the titlebar. Typically this will be the same as
           $[w.name] once expanded, although in the case of using IndexedWindowName then this is
           more useful a distinction, and allows for referencing the specific window by its
           visible name for inclusion in things like Style commands.

       $[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 window is associated with the command or the window is iconified, the string is
           left as is.

       $[w.pagex] $[w.pagey]
           The X or Y page the window is on.

       $[w.desk]
           The number of the desk on which the window is shown. If the window is sticky the
           current desk number is used.

       $[w.layer]
           The layer of the window.

       $[w.screen]
           The screen name the window is on. If RandR is not present, this does not expand.

       $[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 variables are not expanded.

       $[pointer.screen]
           The screen name the pointer is currently on. No expansion if RandR is not enabled.

           This is deprecated; use $[monitor.current] instead.

       $[monitor.<n>.x], $[monitor.<n>.y], $[monitor.<n>.width], $[monitor.<n>.height],
       $[monitor.<n>.desk], $[monitor.<n>.pagex], $[monitor.<n>.pagey] $[monitor.primary],
       $[monitor.current], $[monitor.prev] $[monitor.output], $[monitor.count],
       $[monitor.<n>.prev_desk], $[monitor.<n>.prev_pagex], $[monitor.<n>.prev_pagey]
           Returns information about the selected monitor. These can be nested, for example:
           $[monitor.$[monitor.primary].width]

           <n> should be a valid xrandr(1) output name.

           "x" returns the monitor’s x position; "y" returns the monitor’s y position; "width"
           returns the monitor’s width (in pixels); "height" returns the monitor’s height (in
           pixels)

           "current" is the same as the deprecated $[screen.pointer] variable; the monitor which
           has the mouse pointer.

           "prev" returns the previously focused monitor, or the empty string if there isn’t one.

           "count" returns the number of active monitors.

           "desk" returns the current desk displayed on the referenced monitor.

           "pagex" returns the X page on the referenced monitor.

           "pagey" returns the Y page of the referenced monitor.

           "primary" is the name of the output set as primary via xrandr(1).

           "prev_desk" returns the previous desk on the referenced monitor.

           "prev_pagex" returns the previous X page on the referenced monitor.

           "prev_pagey" returns the previous Y page on the referenced monitor.

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

       $[screen.count]
           The total number of screens detected. Assumes RandR.

           This is deprecated; use $[monitor.count] instead.

       $[fg.cs<n>] $[bg.cs<n>] $[hilight.cs<n>] $[shadow.cs<n>] $[fgsh.cs<n>]
           These parameters are replaced with the name of the foreground (fg), background (bg),
           hilight (hilight), shadow (shadow), or the font shadow (fgsh) color that is defined in
           colorset <n> (replace <n> with zero or a positive integer). For example "$[fg.cs3]" is
           expanded to the name of the foreground color of colorset 3 (in rgb:rrrr/gggg/bbbb
           form).

           If .lighten<p> or .darken<p> is appended to the parameters, they are instead replaced
           with a color that is lighter or darker than the one defined in colorset <n> by a
           percentage value <p> (between 0 and 100). For example "$[bg.cs3.lighten15]" is
           expanded to the background color of colorset 3 and then lightened 15% (in
           rgb:rrrr/gggg/bbbb form).

           If .hash is appened to the end the color output will use #rrggbb form (instead of
           rgb:rrrr/gggg/bbbb). For example, $[bg.cs3.hash] or $[bg.cs3.lighten15.hash].

           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.

       $[func.context]
           The context character of the running command as used in the Mouse, Key or PointerKey
           command. This is useful for example with:

               Mouse 3 FS N WindowShade $$[func.context]

       $[debuglog.state]
           Either 0 (debug log closed) or 1. Indicates the current state of debugging and logging
           facility.

       $[gt.str]
           return the translation of str by looking in the current locale catalogs. If no
           translation is found str is returned as is. See the LocalePath command.

       $[infostore.key]
           Return the value of the item stored in the InfoStore at the given key. If no key is
           present, the unexpanded string is returned.

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

MENU CONCEPTS AND COMMANDS

       Please refer to the fvwm3menus man page.

LIST OF FVWM COMMANDS

       Please refer to the fvwm3commands and fvwm3styles man pages.

ENVIRONMENT

       The environment variables that have an effect on how fvwm operates are the following:

       DISPLAY
           Fvwm starts on this display unless the -display option is given.

       FVWM_USERDIR
           Used to determine the user’s data directory for reading and writing files. If this
           variable is not already set, it is set by fvwm to $HOME/.fvwm, which is the default
           user’s data directory.

       FVWM3_LOGFILE
           Used to determine the path and filename to log debug information from fvwm3. By
           default debug log is written to $FVWM_USERDIR/fvwm3-output.log . If an absolute path
           is specified (starting with /) then $FVWM_USERDIR is ignored, otherwise the log is
           written to $FVWM_USERDIR/$FVWM3_LOGFILE .

       FVWM_DATADIR
           Set by fvwm to the directory containing fvwm config and module data.

       FVWM_MODULEDIR
           Set by fvwm to the directory containing the standard fvwm modules.

       SESSION_MANAGER
           Fvwm tries to contact this session manager.

       SESSION_MANAGER_NAME
           This is used mainly to determine xsm running to work around its bug. If this variable
           is set to "xsm", DiscardCommand is set as xsm expects it and not as XSMP requires. If
           you run fvwm under xsm, you should set this variable to "xsm", otherwise old state
           files are not removed.

       SM_SAVE_DIR
           If this is set, fvwm saves its session data in this directory. Otherwise it uses
           $HOME. Note, the state files are named .fs-?????? and normally are removed
           automatically when not used anymore.

AUTHORS

       Robert Nation with help from many people, based on twm code, which was written by Tom
       LaStrange. After Robert Nation came Charles Hines, followed by Brady Montz. Currently fvwm
       is developed by a number of people on the fvwm-workers mailing list.

COPYRIGHT

       Fvwm and all the modules, scripts and other files coming with the distribution are subject
       to the GNU General Public License (GPL). Please refer to the COPYING file that came with
       fvwm for details.

BUGS

       Bug reports can be sent to the fvwm-workers mailing list at fvwm-workers@fvwm.org

       The official fvwm homepage is http://fvwm.org/.

                                            2023-09-19                                   FVWM3(1)