/* Define for fancy, multi-pixmap-themeable titlebars */

#define FANCY_TITLEBARS

#ifdef FANCY_TITLEBARS

  case MultiPixmap:       /* in case of UseTitleStyle */

#endif

#ifdef FANCY_TITLEBARS

    else if (type == MultiPixmap) {

      if (left1right0 && df->u.multi_pixmaps[TBP_LEFT_BUTTONS])

        p = df->u.multi_pixmaps[TBP_LEFT_BUTTONS];

      else if (!left1right0 && df->u.multi_pixmaps[TBP_RIGHT_BUTTONS])

        p = df->u.multi_pixmaps[TBP_RIGHT_BUTTONS];

      else if (df->u.multi_pixmaps[TBP_BUTTONS])

        p = df->u.multi_pixmaps[TBP_BUTTONS];

      else if (left1right0 && df->u.multi_pixmaps[TBP_LEFT_MAIN])

        p = df->u.multi_pixmaps[TBP_LEFT_MAIN];

      else if (!left1right0 && df->u.multi_pixmaps[TBP_RIGHT_MAIN])

        p = df->u.multi_pixmaps[TBP_RIGHT_MAIN];

      else

        p = df->u.multi_pixmaps[TBP_MAIN];

    }

#endif

#ifdef FANCY_TITLEBARS

          type == MultiPixmap ||

#endif

#ifdef FANCY_TITLEBARS

/****************************************************************************

 *

 *  Tile or stretch src into dest, starting at the given location and

 *  continuing for the given width and height. This is a utility function used

 *  by DrawMultiPixmapTitlebar. (tril@igs.net)

 *

 ****************************************************************************/

static void RenderIntoWindow(GC gc, Picture *src, Window dest, int x_start,

                             int y_start, int width, int height, Bool stretch)

{

  Pixmap pm;

  if (stretch)

    pm = CreateStretchPixmap(dpy, src->picture, src->width, src->height,

                             src->depth, width, height, gc);

  else

    pm = CreateTiledPixmap(dpy, src->picture, src->width, src->height,

                           width, height, src->depth, gc);

  XCopyArea(dpy, pm, dest, gc, 0, 0, width, height, x_start, y_start);

  XFreePixmap(dpy, pm);

}

/****************************************************************************

 *

 *  Redraws multi-pixmap titlebar (tril@igs.net)

 *

 ****************************************************************************/

static void DrawMultiPixmapTitlebar(FvwmWindow *window, DecorFace *df)

{

  Window       title_win;

  GC           gc;

  const char  *title;

  Picture    **pm;

  short        stretch_flags;

  int          title_width, title_height, text_width, text_offset, text_y_pos;

  int          left_space, right_space, under_offset, under_width;

  pm = df->u.multi_pixmaps;

  stretch_flags = df->u.multi_stretch_flags;

  gc = Scr.TitleGC;

  XSetClipMask(dpy, gc, None);

  title_win = window->title_w;

  title = window->name;

  title_width = window->title_g.width;

  title_height = window->title_g.height;

  if (pm[TBP_MAIN])

    RenderIntoWindow(gc, pm[TBP_MAIN], title_win, 0, 0, title_width,

                     title_height, (stretch_flags & (1 << TBP_MAIN)));

  else if (!title)

    RenderIntoWindow(gc, pm[TBP_LEFT_MAIN], title_win, 0, 0, title_width,

                     title_height, (stretch_flags & (1 << TBP_LEFT_MAIN)));

  if (title) {

#ifdef I18N_MB

    text_width = XmbTextEscapement(window->title_font.fontset, title,

                                   strlen(title));

#else

    text_width = XTextWidth(window->title_font.font, title, strlen(title));

#endif

    if (text_width > title_width)

      text_width = title_width;

    switch (TB_JUSTIFICATION(GetDecor(window, titlebar))) {

    case JUST_LEFT:

      text_offset = TITLE_PADDING;

      if (pm[TBP_LEFT_OF_TEXT])

        text_offset += pm[TBP_LEFT_OF_TEXT]->width;

      if (pm[TBP_LEFT_END])

        text_offset += pm[TBP_LEFT_END]->width;

      if (text_offset > title_width - text_width)

        text_offset = title_width - text_width;

      break;

    case JUST_RIGHT:

      text_offset = title_width - text_width - TITLE_PADDING;

      if (pm[TBP_RIGHT_OF_TEXT])

        text_offset -= pm[TBP_RIGHT_OF_TEXT]->width;

      if (pm[TBP_RIGHT_END])

        text_offset -= pm[TBP_RIGHT_END]->width;

      if (text_offset < 0)

        text_offset = 0;

      break;

    default:

      text_offset = (title_width - text_width) / 2;

      break;

    }

    under_offset = text_offset;

    under_width = text_width;

    /* If there's title padding, put it *inside* the undertext area: */

    if (under_offset >= TITLE_PADDING) {

      under_offset -= TITLE_PADDING;

      under_width += TITLE_PADDING;

    }

    if (under_offset + under_width + TITLE_PADDING <= title_width)

      under_width += TITLE_PADDING;

    left_space = under_offset;

    right_space = title_width - left_space - under_width;

    if (pm[TBP_LEFT_MAIN] && left_space > 0)

      RenderIntoWindow(gc, pm[TBP_LEFT_MAIN], title_win, 0, 0, left_space,

                       title_height, (stretch_flags & (1 << TBP_LEFT_MAIN)));

    if (pm[TBP_RIGHT_MAIN] && right_space > 0)

      RenderIntoWindow(gc, pm[TBP_RIGHT_MAIN], title_win,

                       under_offset + under_width, 0, right_space,

                       title_height, (stretch_flags & (1 << TBP_RIGHT_MAIN)));

    if (pm[TBP_UNDER_TEXT] && under_width > 0)

      RenderIntoWindow(gc, pm[TBP_UNDER_TEXT], title_win, under_offset, 0,

                       under_width, title_height,

                       (stretch_flags & (1 << TBP_UNDER_TEXT)));

    if (pm[TBP_LEFT_OF_TEXT] &&

        pm[TBP_LEFT_OF_TEXT]->width <= left_space) {

      XCopyArea(dpy, pm[TBP_LEFT_OF_TEXT]->picture, title_win, gc, 0, 0,

                pm[TBP_LEFT_OF_TEXT]->width, title_height,

                under_offset - pm[TBP_LEFT_OF_TEXT]->width, 0);

      left_space -= pm[TBP_LEFT_OF_TEXT]->width;

    }

    if (pm[TBP_RIGHT_OF_TEXT] &&

        pm[TBP_RIGHT_OF_TEXT]->width <= right_space) {

      XCopyArea(dpy, pm[TBP_RIGHT_OF_TEXT]->picture, title_win, gc, 0, 0,

                pm[TBP_RIGHT_OF_TEXT]->width, title_height,

                under_offset + under_width, 0);

      right_space -= pm[TBP_RIGHT_OF_TEXT]->width;

    }

    text_y_pos = title_height

                 - (title_height - window->title_font.font->ascent) / 2

                 - 1;

    if (title_height > 19)

      text_y_pos--;

    if (text_y_pos < 0)

      text_y_pos = 0;

#ifdef I18N_MB

    XmbDrawString(dpy, title_win, window->title_font.fontset, gc, text_offset,

                  gc, text_offset, text_y_pos, title, strlen(title));

#else

    XDrawString(dpy, title_win, gc, text_offset, text_y_pos, title,

                strlen(title));

#endif

  }

  else

    left_space = right_space = title_width;

  if (pm[TBP_LEFT_END] && pm[TBP_LEFT_END]->width <= left_space)

    XCopyArea(dpy, pm[TBP_LEFT_END]->picture, title_win, gc, 0, 0,

              pm[TBP_LEFT_END]->width, title_height, 0, 0);

  if (pm[TBP_RIGHT_END] && pm[TBP_RIGHT_END]->width <= right_space)

    XCopyArea(dpy, pm[TBP_RIGHT_END]->picture, title_win, gc, 0, 0,

              pm[TBP_RIGHT_END]->width, title_height,

              title_width - pm[TBP_RIGHT_END]->width, 0);

}

#endif /* FANCY_TITLEBARS */

  int left1right0;

#ifdef FANCY_TITLEBARS

    if (df->style.face_type == MultiPixmap)

      DrawMultiPixmapTitlebar(t, df);

    else

#endif

#ifdef FANCY_TITLEBARS

    if (TB_STATE(GetDecor(t, titlebar))[title_state].style.face_type

        != MultiPixmap)

#endif

    {

    }

#ifdef FANCY_TITLEBARS

static char *ReadMultiPixmapDecor(char *s, DecorFace *df);

#endif

#ifdef FANCY_TITLEBARS

  int i;

#endif

#ifdef FANCY_TITLEBARS

  case MultiPixmap:

    if (df->u.multi_pixmaps) {

      for (i=0; i < NUM_TB_PIXMAPS; i++) {

        if (df->u.multi_pixmaps[i])

          DestroyPicture(dpy, df->u.multi_pixmaps[i]);

      }

      free(df->u.multi_pixmaps);

    }

    break;

#endif

#ifdef FANCY_TITLEBARS

    else if (strncasecmp(style,"MultiPixmap",11)==0) {

      if (button != -1) {

        if (verbose)

          fvwm_msg(ERR, "ReadDecorFace",

                   "MultiPixmap is only valid for TitleStyle");

        return False;

      }

      s = ReadMultiPixmapDecor(s, df);

      if (!s)

        return False;

    }

#endif

#ifdef FANCY_TITLEBARS

/*****************************************************************************

 *

 * Reads a multi-pixmap titlebar config. (tril@igs.net)

 *

 ****************************************************************************/

static char *ReadMultiPixmapDecor(char *s, DecorFace *df)

{

  static char *pm_names[NUM_TB_PIXMAPS+1] = {

    "Main",

    "LeftMain",

    "RightMain",

    "UnderText",

    "LeftOfText",

    "RightOfText",

    "LeftEnd",

    "RightEnd",

    "Buttons",

    "LeftButtons",

    "RightButtons",

    NULL

  };

  Picture **pm;

  char *token;

  Bool stretched;

  int pm_id, i;

  df->style.face_type = MultiPixmap;

  df->u.multi_pixmaps = pm =

    (Picture**)safecalloc(NUM_TB_PIXMAPS, sizeof(Picture*));

  s = GetNextTokenIndex(s, pm_names, 0, &pm_id);

  while (pm_id >= 0) {

    s = DoPeekToken(s, &token, ",()", NULL, NULL);

    stretched = False;

    if (StrEquals(token, "stretched")) {

      stretched = True;

      s = DoPeekToken(s, &token, ",", NULL, NULL);

    }

    else if (StrEquals(token, "tiled"))

      s = DoPeekToken(s, &token, ",", NULL, NULL);

    if (!token)

      break;

    if (pm[pm_id]) {

      fvwm_msg(WARN, "ReadMultiPixmapDecor",

               "Ignoring already-specified %s pixmap", pm_names[i]);

      continue;

    }

    if (stretched)

      df->u.multi_stretch_flags |= (1 << pm_id);

    pm[pm_id] = CachePicture(dpy, Scr.NoFocusWin, NULL, token, Scr.ColorLimit);

    if (!pm[pm_id])

      fvwm_msg(ERR, "ReadMultiPixmapDecor", "Pixmap '%s' could not be loaded",

               token);

    s = GetNextTokenIndex(s, pm_names, 0, &pm_id);

  }

  if (!pm[TBP_MAIN] && !(pm[TBP_LEFT_MAIN] && pm[TBP_RIGHT_MAIN])) {

    fvwm_msg(ERR, "ReadMultiPixmapDecor",

             "No Main pixmap found for TitleStyle MultiPixmap "

             "(you must specify either Main, or both LeftMain and RightMain)");

    for (i=0; i < NUM_TB_PIXMAPS; i++) {

      if (pm[i])

        DestroyPicture(dpy, pm[i]);

    }

    free(pm);

    return NULL;

  }

  return s;

}

#endif /* FANCY_TITLEBARS */

If fvwm is compiled with the FANCY_TITLEBARS option enabled, an additional

TitleStyle is available: MultiPixmap. This allows you to specify different

pixmaps for different parts of the titlebar. Some of them are tiled or

stretched to fit a particular space; others are discrete "transition" pixmaps

which are not resized in any way. The definable pixmaps are:

.EX

- Main (tiled/stretched): The main titlebar pixmap

- LeftMain (tiled/stretched): Left of title text

- RightMain (tiled/stretched): Right of title text

- UnderText (tiled/stretched): Underneath title text

- LeftOfText: Pixmap just to the left of the title text

- RightOfText: Pixmap just to the right of the title text

- LeftEnd: Pixmap at the far left end of the titlebar

  (just before buttons)

- RightEnd: Pixmap at the far right end of the titlebar

  (just before buttons)

- Buttons (tiled): Tiled under buttons in case of

  UseTitleStyle

- LeftButtons (tiled): Tiled under left buttons in case of

  UseTitleStyle

- RightButtons (tiled): Tiled under right buttons in case of

  UseTitleStyle

.EE

None of these are mandatory except for Main (or, if you don't define Main,

you must define both LeftMain and RightMain). If no "Buttons" pixmaps are

defined and UseTitleStyle is specified for one or more buttons, Main,

LeftMain, or RightMain will be used as appropriate.

The syntax for this style type is:

.EX

MultiPixmap <section> (<flag>) <pixmap filename>, ...

.EE

continuing for whatever pixmaps you want to define. By default, all

non-transition pixmaps are tiled. If you want one stretched instead (this is

allowed for Main, LeftMain, RightMain, and UnderText), add "(stretched)" after

the section name:

.EX

MultiPixmap Main (stretched) foo.xpm, UnderText bar.xpm

.EE

Otherwise you can omit (<flag>), as shown with UnderText.

.\" Formatting instructions for the fvwm man page:

.\"

.\"  - Do not use \f... formatting instructions

.\"    unless you have to, see below.

.\"  - Avoid single and double quotes wherever possible.

.\"

.\" For further details, please refer to the Linux Man-Page how-to.

.\"

.\"  context                                typeface       example

.\"  ---------------------------------- --------------  -----------------

.\"  filenames:                         italics (.I)    .I .fvwm2rc

.\"  command line options of fvwm2 cmd: bold (.B)       .B \-cmd

.\"  arguments of command line options: italics (.I)    .BI \-cmd command

.\"  built in commands:                 bold (.B)       .B Move

.\"  references to built in commands:   bold (.B)       .RB See Move

.\"  references to man page sections:   bold (.B)       .RB See SYNOPSIS

.\"  references to style options:       italics (.I)    .RI See Lenience

.\"  built in command options:          italics (.I)    .BI "Move " "0 0"

.\"  command syntax:                    bold/ita. (.BI) .BI "Move [" "x y" "]"

.\"  environment variables:             italics (.I)    .I $DISPLAY

.\"  key names:                         small (.SM)     .SM Tab

.\"  style names and strings:           double quotes   "stylename", "x"

.\"  single characters:                 single quotes   '@'

.\"  module names:                      bold (.B)       .B FvwmTheme

.\"  links to web pages:                bold (.B)       .B http://fvwm.org

.\"  acronyms:                          small (.SM)     .SM ICCCM

.\"

.\"

.\" The name fvwm is written in lower case throughout this man

.\" page.

.\"

.\" Note that the word "will" is rarely correct in a man page or

.\" any document. Describe what fvwm does, not what it will do,

.\" even if you haven't written the feature yet. dje 2/3/01

.\" (3/Feb/2001).

.\"

.\" A note to everyone who needs to write dates.  Don't use 2/3/01

.\" notation, a non-american person simply can't parse such

.\" sequence of digits.  Please use 3-Feb-2001 or 2001-02-03 forms.

.\" migo 16/May/2001.

.\"

.\" A note about the rule against \f... formatting.  On Solaris,

.\" AIX, and HPUX the ".BI" type commands are limited to 6

.\" arguments. use \f... formatting in that case.  See the lines

.\" formatted with ".IP".

.\"  dje 15/June/2001.

.\"

.\" @(#)fvwm-2.4.7 11 Apr 2002

.de EX		\"Begin example

.ne 5

.if n .sp 1

.if t .sp .5

.nf

.in +.5i

..

.de EE

.fi

.in -.5i

.if n .sp 1

.if t .sp .5

..

.ta .3i .6i .9i 1.2i 1.5i 1.8i

.TH FVWM2 1 "11 Apr 2002"

.UC

.SH NAME

fvwm2 \- F(?) Virtual Window Manager (version 2) for X11

.SH SYNOPSIS

.B fvwm2

.RB [ \-blackout ]

.RB [ \-clientId

.IR       id ]

.RB [ \-cmd

.IR       config_command ]

.RB [ \-d

.IR       displayname ]

.RB [ \-debug ]

.RB [ \-debug_stack_ring ]

.RB [ \-f

.IR       config_file ]

.RB [ \-h ]

.RB [ \-replace ]

.RB [ \-restore

.IR       state_file ]

.RB [ \-s ]

.RB [ \-version ]

.RB [ \-visual

.IR       visual_class ]

.RB [ \-visualId

.IR       id ]

.SH DESCRIPTION

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, although the

executable program is named fvwm2.  There is an fvwm offspring

called fvwm95. Although it is very similar to older versions of

fvwm version 2 it is technically a different window manager that

has been developed by different people.  The main goal of fvwm95

was to supply a Windows 95 like look and feel.  Since then fvwm

has been greatly enhanced and only very few features of fvwm95 can

not be imitated by fvwm.  No active development has been going on

for fvwm95 for several years now.  Unfortunately Red Hat (a

popular Linux distributor) has a pre-configured fvwm package based

on fvwm version 2.x that is called fvwm95 too.

Fvwm provides both a large

.I virtual desktop

and

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

.I 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 blurred the distinction between configuration

commands and built-in commands that most window-managers make.

Configuration commands typically set fonts, colors, menu contents,

key and mouse function bindings, while built-in commands typically

do things like raise and lower windows.  Fvwm makes no such

distinction, and allows, to the extent that is practical, anything

to be changed at any time.

Other noteworthy differences between Fvwm and other X11 window

managers are the introduction of the

.I SloppyFocus " and " NeverFocus

focus methods.  Focus policy can be specified for individual

windows.  Windows using

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

.I NeverFocus

policy is provided for use with windows into which one never types

(e.g. xclock, oclock, xbiff, xeyes, tuxeyes) - for example, if a

SloppyFocus terminal window has focus, moving the cursor over a

.I NeverFocus

decoration window won't deprive the terminal of focus.

.SH OPTIONS

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

.TP

.BI "-blackout"

This option is provided for backward compatibility only.  Blacking

out the screen during startup is not necessary anymore.

.TP

.BI "-clientId " id

This option is used when fvwm is started by a session

manager. Should not be used by a user.

.TP

.BI "-cmd " config_command

Causes fvwm to use

.I config_command

instead of

.RB "'Read"

.IR ".fvwm2rc'"

as its initialization command.  (Note that up to 10

.BR \-f " and " \-cmd

parameters can be given, and they are executed in the order

specified.)

.TP

.BI "-d " displayname

Manage the display called

.I displayname

instead of the name obtained from the environment variable

.IR "$DISPLAY" .

.TP

.BI "-debug"

Puts X transactions in synchronous mode, which dramatically slows

things down, but guarantees that fvwm's internal error messages

are correct. Also causes fvwm to output debug messages while

running.

.TP

.BI "-debug_stack_ring"

Enables stack ring debugging.  This option is only intended for

internal debugging and should only be used by developers.

.TP

.BI "-f " config_file

Causes fvwm to read

.I config_file

instead of

.I .fvwm2rc

as its initialization file.  This is equivalent to

.RB "-cmd 'Read"

.IR "config_file'."

.

.TP

.BI "-h"

A short usage description is printed.

.TP

.BI "-replace"

Try to take over from a previously running wm.  This does not work

unless the other wm is

.SM ICCCM

2.0 compliant.

.TP

.BI "-restore " state_file

This option is used when fvwm is started by a session manager.

Should not be used by a user.

.TP

.BI "-s"

On a multi-screen display, run fvwm only on the screen named in

the

.I $DISPLAY

environment variable or provided through the

.B -d

option. Normally, fvwm attempts to start up on all screens of a

multi-screen display.

.TP

.BI "-version"

Prints the version of fvwm to

.IR stderr .

Also prints an information about the compiled in support for

readline, rplay, stroke, xpm, gnome hints, session management and

multibyte characters.

.TP

.BI "-visual " visual_class

Causes fvwm to use

.I visual_class

for the window borders and menus.

.I visual_class

can be "StaticGray", "GrayScale", "StaticColor", "PseudoColor",

"TrueColor" or "DirectColor".

.TP

.BI "-visualId " id

Causes fvwm to use

.I id

as the visualId for the window borders and menus.

.I id

can be specified as N for decimal or 0xN for hexadecimal. See man

page of xdpyinfo for a list of supported visuals.

.SH ANATOMY OF A WINDOW

Fvwm puts a decorative border around most windows.  This border

consists of a bar on each side and a small L-shaped section on

each corner.  There is an additional top bar called the title-bar

which is used to display the name of the window.  In addition,

there are up to 10 title-bar buttons.  The top, side, and bottom

bars are collectively known as the side-bars.  The corner pieces

are called the frame.

Unless the standard defaults files are modified, pressing mouse

button 1 in the title or side-bars begins a move operation on the

window.  Pressing button 1 in the corner frame pieces begins a

resize operation.  Pressing button 2 anywhere in the border brings

up an extensive list of window operations.

Up to ten title-bar buttons may exist.  Their use is completely

user definable.  The default configuration has a title-bar button

on each side of the title-bar.  The one on the left is used to

bring up a list of window options, regardless of which mouse

button is used.  The one on the right is used to iconify the

window.  The number of title-bar buttons used depends on which

ones have mouse actions bound to them.  See the section on the

.B Mouse

command below.

.SH THE VIRTUAL DESKTOP

Fvwm provides multiple virtual desktops for users who wish to use

them.  The screen is a viewport onto a

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

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

.B DeskTopSize

built-in command.  All virtual desktops must be (are) the same

size.  The total number of distinct desktops does not need to be

specified, but is limited to approximately 4 billion total. All

windows on a range of desktops can be viewed in the

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

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

.B Layer

command.  The concept of layers is a generalization of the

.I StaysOnTop

flag of older fvwm versions. The

.IR StaysOnTop " and " StaysPut

.B Style

options are now implemented by putting the windows in suitable

layers and the previously missing

.IB "StaysOnBottom " Style

option has been added.

.B Sticky

windows are windows which transcend the virtual desktop by

"Sticking to the screen's glass".  They always stay put on the

screen. This is convenient for things like clocks and xbiff's, so

you only need to run one such 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:

.EX

xterm -geometry +0+0

.EE

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:

.EX

xterm -geometry +1000+1000

.EE

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:

.EX

xterm -geometry -5-5

.EE

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

.IR StartsOnPage or StartsOnScreen

style specification (the successors to the older

.I StartsOnDesk

style) in the

.I .fvwm2rc

configuration file.  The placement is consistent: it does not

depend on your current location on the virtual desktop.

Some applications that understand standard Xt command line

arguments and X resources, like xterm and xfontsel, allow the user

to specify the start-up desk or page on the command line:

.EX

xterm -xrm "*Desk:1"

.EE

starts an xterm on desk number 1;

.EX

xterm -xrm "*Page:3 2 1"

.EE

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

.I .Xdefaults

file:

.EX

XTerm*Desk: 1

.EE

or

.EX

XTerm*Page: 3 2 1

.EE

.SH USE ON MULTI-SCREEN DISPLAYS

If the

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

.EX

 EdgeScroll 0 0

.EE

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.

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

.BI EdgeResistance

command allows to specify an explicit resistance value for moving

windows over the screen edge between two Xinerama screens.

Xinerama support can be enabled or disabled on the fly or from the

configuration file with the

.B Xinerama

command.  Many modules and commands work nicely with Xinerama

displays.

Everywhere where a geometry in the usual X format can be supplied,

fvwm's Xinerama extension allows to specify a screen in addition

to the geometry (or even the screen alone).  To do this, a '@' is

added to the end of the geometry string followed by either the

screen number or a letter.  A number is taken as the number of the

Xinerama screen to be used (as configured in the X server).  The

letter can be one of 'g' for the global screen (the 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.

.EX

Style * IconBox 64x300-0-0@p

.EE

Xinerama support can be configured to use a primary screen.  Fwvm

can be configured to place new windows and icons on this screen.

The primary screen is screen 0 by default but can be changed with

the

.B XineramaPrimaryScreen

command.

Xinerama support was designed to work out of the box with the same

configurations file that would work on a single screen.  It may

not work too well if the involved screens use different screen

resolutions.  In this situation, windows may get stuck in the

portion of the whole desktop that belongs to neither screen.  If

this happens, the windows or icons can be retrieved with the

command

.EX

All MoveToScreen

.EE

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

.BR XineramaSls " and " XineramaSlsSize

are used to configure this feature.

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

.EX

.BI "Read " .fvwm2rc

.EE

This looks for

.IR .fvwm2rc " in "

.IR "$HOME/.fvwm" " or " "$FVWM_USERDIR"

directories, as described in

.B Read

below.  If this fails, fvwm also searches for this file in the

.I $HOME

directory or for

.I system.fvwm2rc

file in the system place.  If a configuration file is not found,

any mouse button or the

.SM Help

or

.SM F1

keys on the root window brings up menus and forms that can create

a starting configuration file.

Fvwm sets two environment variables which are inherited by its

children.  These are

.I $DISPLAY

which describes the display on which fvwm is running.

.I $DISPLAY

may be

.I unix:0.0

or

.IR ":0.0" ,

which doesn't work too well when passed through rsh to another

machine, so

.I $HOSTDISPLAY

is set to a network-ready description of the display.

.I $HOSTDISPLAY

always uses the TCP/IP transport protocol (even for a local

connection) so

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

.EX

Exec app

.EE

or

.EX

Module FvwmXxx

.EE

into your

.IR .fvwm2rc ,

but it is not recommended; do this only if you know what you are

doing. It is usually critical to start applications or modules

after

.I .fvwm2rc

is read, because it contains styles or module configurations which

can affect window appearance and functionality.

The standard way to start applications or modules on fvwm's start

up is to add them to an initialization function (usually

.BR StartFunction " or " InitFunction ).

This way they are only started after fvwm reads the entire

.IR .fvwm2rc .

Fvwm has three special functions for initialization:

.BR StartFunction ,

which is executed on startups and restarts;

.BR InitFunction " and " RestartFunction ,

which are executed during initialization and restarts

(respectively) just after StartFunction. These functions may be

customized in a user's

.I .fvwm2rc

file via the

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

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

.BR SessionInitFunction " and " SessionRestartFunction

are executed instead of InitFunction and RestartFunction.

This helps to define the user's

.I .fvwm2rc

file to be good for both running under a session manager and

without it.  Generally it is a bad idea to start xterms or other

applications in "Session*" functions.  Also someone can decide to

start different modules while running under a session manager or

not.  For the similar purposes

. B SessionExitFunction

is used instead of ExitFunction.

.EX

DestroyFunc StartFunction

AddToFunc StartFunction

 + I ModuleSynchronous FvwmTheme

 + I Module FvwmPager * *

 + I Module FvwmButtons

DestroyFunc InitFunction

AddToFunc InitFunction

 + I Module FvwmBanner

 + I Module FvwmTaskBar

 + I xsetroot -solid cyan

 + I Exec xterm

 + I Exec netscape

DestroyFunc RestartFunction

AddToFunc RestartFunction

 + I Module FvwmTaskBar

DestroyFunc SessionInitFunction

AddToFunc SessionInitFunction

 + I Module FvwmBanner

DestroyFunc SessionRestartFunction

AddToFunc SessionRestartFunction

 + I Nop

.EE

You don't need to define all special functions if some are empty.

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

.I config.h

file that is generated during compilation.

.SH ICONS

The basic fvwm configuration uses monochrome bitmap icons.  If

.B XPM

extensions are compiled in, then color icons can be used. In order

to use these options you need the XPM package, as described in the

.I INSTALL.fvwm

file.

If both the

.BR SHAPE " and " XPM

options are compiled in you get shaped color icons, which are very

spiffy.

.SH MODULES

A module is a separate program which runs as a separate Unix

process but transmits commands to fvwm to execute.  Users can

write their own modules to do any weird or bizarre manipulations

without bloating or affecting the integrity of fvwm itself.

Modules must be spawned by fvwm so that it can set up two pipes

for fvwm and the module to communicate with.  The pipes are

already open for the module when it starts and the file

descriptors for the pipes are provided as command line arguments.

Modules can be spawned during fvwm at any time during the X

session by use of the

.B Module

built-in 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 text commands to the fvwm built-in command

engine.  Text commands are formatted just as in the case of a

mouse binding in the

.I .fvwm2rc

setup file.  Certain auxiliary information is also transmitted, as

in the sample module

.BR FvwmButtons .

The

.B FvwmButtons

module is documented in its own man page.

Please refer to the

.B "MODULE COMMANDS"

section for details.

.SH ICCCM COMPLIANCE

Fvwm attempts to be

.SM ICCCM

2.0 compliant.  In addition,

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

.SM ICCCM

states that windows possessing the property

.EX

WM_HINTS(WM_HINTS):

    Client accepts input or input focus: False

.EE

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,

.IR Lenience ", "

which allows fvwm to overlook this

.SM ICCCM

rule.  Even with this window-style it is not guaranteed that the

application accepts focus.

The differences between

.SM ICCCM

1.1 and 2.0 include the ability to take over from a running

.SM ICCCM

2.0 compliant window manager; thus

.EX

fvwm2; vi .fvwm2rc; fvwm2 -replace

.EE

resembles the

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

.IR .Xclients " or " .Xsession

file.

Further additions are support for client-side colormap

installation (see the .SM ICCCM for details) and the urgency hint.

Clients can set this hint in the WM_HINTS property of their window

and expect the window manager to attract the users attention to

the window.  Fvwm has two re-definable functions for this purpose,

"UrgencyFunc" and "UrgencyDoneFunc", which are executed when the

flag is set/cleared.  Their default definitions are:

.EX

AddToFunc UrgencyFunc

 + I Iconify off

 + I FlipFocus

 + I Raise

 + I WarpToWindow 5p 5p

AddToFunc UrgencyDoneFunc

 + I Nop

.EE

.SH GNOME COMPLIANCE

Fvwm attempts to be

.SM GNOME

compliant.  Check

.B http://www.gnome.org

for what that may mean.

.SM GNOME

support is a compile time option which is on by default.  To

disable GNOME hints for some or all windows, the

.I GNOMEIgnoreHints

style can be used.

.SH MWM COMPATIBILITY

Fvwm provides options to emulate Motif Window Manager (Mwm) as

well as possible.  Please refer to the

.B Emulate

command as well as to the Mwm specific options of the

.BR Style " and " MenuStyle

commands for details.

.SH OPEN LOOK and XVIEW COMPATIBILITY

Fvwm supports all the Open Look decoration hints (except

pushpins). 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. Should you use any such application, please add the

following line to your .fvwm2rc:

.EX

Style * OLDecor

.EE

.SH M4 PREPROCESSING

.PP

M4 pre-processing is handled by a module in fvwm.  To get more

details, try man

.BR FvwmM4 .

In short, if you want fvwm to parse your files with m4, then

replace the command

.B Read

with

.B FvwmM4

in your

.I .fvwm2rc

file (if it appears at all), and start fvwm with the command

.EX

fvwm2 -cmd "FvwmM4 .fvwm2rc"

.EE

.SH CPP PREPROCESSING

.PP

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 above, but replace "m4" with "cpp".

.SH AUTO-RAISE

.PP

Windows can be automatically raised when it receives focus, or

some number of milliseconds after it receives focus, by using the

auto-raise module,

.BR FvwmAuto .

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

.IR .fvwm2rc .

By using the

.B Read

built-in, it is easy to read in new configuration files as you go.

Lines beginning with '#' are ignored by fvwm.  Lines starting with

'*' are expected to contain module 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

built-in commands, so anything mentioned in the built-in commands

section can be placed on a line by itself for fvwm to execute as

it reads the configuration file, or it can be placed as an

executable command in a menu or bound to a mouse button or a

keyboard key.  It is left as an exercise for the user to decide

which function make sense for initialization and which ones make

sense for run-time.

.SH SUPPLIED CONFIGURATION

A sample configuration file,

.IR .fvwm2rc ,

is supplied with the fvwm distribution.  It is well commented and

can be used as a source of examples for fvwm configuration.

.\" .SH INTERNATIONALIZATION

.\" Internationalized fvwm enables to display not only LATIN-1

.\" characters but also multi byte characters such as Japanese,

.\" Korean, etc. You should set up your environment variable

.\" .IR LC_TYPE " or " LANG ,

.\" to enable this feature.  Also, you should specify proper

.\" .I FONTSET

.\" instead of

.\" .IR FONT .

.\" Note that no catalog-file or input-methods are implemented.

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

.B Scroll

built-in to appropriate keys,

.BR Popup ", " Move ", " Resize ", "

and most other built-ins can be bound to keys.  Once a built in

function is started the pointer is moved by using the up, down,

left, and right arrows, and the action is terminated by pressing

return.  Holding down the

.SM Shift

key causes the pointer movement to go in larger steps and holding

down the

.SM control

key causes the cursor movement to go in smaller steps. Standard

emacs and vi cursor movement controls (

.SM Ctrl-n,

.SM Ctrl-p,

.SM Ctrl-f,

.SM Ctrl-b,

and

.SM Ctrl-j,

.SM Ctrl-k,

.SM Ctrl-h,

.SM Ctrl-l

) can be used instead of the arrow keys.

.SH SESSION MANAGEMENT

Fvwm supports session management according to the X Session

Management Protocol.  It saves and restores window position, size,

stacking order, desk, stickiness, shadedness, 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 on these resources during a

session (e.g. by issuing

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

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

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

.EX

Exec exec killall fvwm2

.EE

still kills all copies of fvwm.  Your system must have the

.B killall

command though.

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

.SH BUILT IN KEY AND MOUSE BINDINGS

The following commands are built-in to fvwm:

.EX

Key Help R A Popup MenuFvwmRoot

Key F1 R A Popup MenuFvwmRoot

Key Tab A M WindowList Root c c NoDeskSort

Key Escape A MC EscapeFunc

Mouse 0 R N Menu MenuFvwmRoot

Mouse 1 TS A FuncFvwmRaiseLowerX Move

Mouse 1 F  A FuncFvwmRaiseLowerX Resize

AddToFunc FuncFvwmRaiseLowerX I Raise

+ M $0

+ D Lower

.EE

The

.SM Help

and

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

.SM Tab

key pressed anywhere with the

.SM Meta

key (same as the

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

.EX

Key Tab A M -

.EE

.SH BUILT IN COMMANDS

Fvwm supports a set of built-in functions which can be bound to

keyboard or mouse buttons.  If fvwm expects to find a built-in

function in a command, but fails, it checks to see if the

specified command should have been

.EX

Function (rest of command)

.EE

or

.EX

Module (rest of command)

.EE

This allows complex functions or modules to be invoked in a manner

which is fairly transparent to the configuration file.

Example: the

.I .fvwm2rc

file contains the line

.EX

HelpMe

.EE

Fvwm looks for a built-in command called "HelpMe", and fails.

Next it looks for a user-defined complex function called "HelpMe".

If no such user defined function exists, Fvwm tries to execute a

module called "HelpMe".

Note: There are many commands that affect look and feel of

specific, some or all windows, like

.BR Style ", " Mouse ", the " FvwmTheme

module and many others.  For performance reasons such changes are

not applied immediately but only when fvwm is idle, i.e. no user

interaction or module input is pending.  Specifically, new

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

.BR UpdateStyles ", " Refresh " or " RefreshWindow

commands.

.SS QUOTING

Quotes are required only when needed to make fvwm consider two or

more words to be a single argument.  Unnecessary quoting is

allowed.  If you want a quote character in your text, you must

escape it by using the backslash character.  For example, if you

have a pop-up menu called "Window-Ops", then you don't need

quotes:

.EX

Popup Window-Ops

.EE

but if you replace the dash with a space, then you need

quotes:

.EX

Popup "Window Ops"

.EE

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.

.SS COMMAND EXPANSION

Whenever a fvwm command line is executed, fvwm performs parameter

expansion.  A parameter is a '$' followed by a single letter or a

word enclosed in brackets ($[...]).  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

quote a '$' use "$$".  Note that module configuration lines

(i.e. lines beginning with '*') are not fully expanded; for

backward compatibility single alphabetic-letter parameters (like

"$d" or "$n") are not expanded in these lines.

The general idea is to expand single letter parameters as soon as

possible.  So a "$d" is expanded immediately when read by the

parser, but "$3" is only expanded in the context of a complex

function with at least four parameters.  Otherwise it is left

untouched.  Similarly, "$c" is only expanded in the context of a

window.

Parameter expansion in the

.BR +

command is different than in normal commands.  If the command is

adding to a function, single letter parameters are expanded

normally which is often not what was intended.  To suppress

expansion the '$' has to be doubled.  Parameters enclosed in

brackets are protected from parameter expansion in these commands

so the '$' must not be doubled.

Example:

.EX

# Print the current desk number, horizontal

# page and the window's class.

Echo $d $[page.nx] $c

# But a function that prints $d needs $$,

# but not before $[page.nx] or $c:

AddToFunc PrintDeskNumber

+ I Echo $$d $[page.nx] $c

.EE

Note: If this funtion is called outside a window context, it will

print "$c" 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

.B Current

command can be used:

.EX

Current Echo $d $[page.nx] $c

.EE

The parameters known by fvwm are:

.in +.5i

$$

.in +.3i

A literal '$'.

.in -.3i

.in -.5i

.in +.5i

$.

.in +.3i

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

.in -.3i

.in -.5i

.in +.5i

$c

.in +.3i

The window's resource class name or "$c" if no window is

associated with the command.

.in -.3i

.in -.5i

.in +.5i

$d

.in +.3i

The current desk number.

.in -.3i

.in -.5i

.in +.5i

$n

.in +.3i

The window's name or "$n" if no window is associated with the

command.

.in -.3i

.in -.5i

.in +.5i

$r

.in +.3i

The window's resource name or "$r" if no window is associated with

the command.

.in -.3i

.in -.5i

.in +.5i

$v

.in +.3i

The first line printed by the -version command line option.

.in -.3i

.in -.5i

.in +.5i

$w

.in +.3i

The window-id (expressed in hex, e.g. 0x10023c) of the window the

command was called for or "$w" if no window is associated with the

command.

.in -.3i

.in -.5i

.in +.5i

$x

.in +.3i

The x coordinate of the current viewport.

.in -.3i

.in -.5i

.in +.5i

$y

.in +.3i

The y coordinate of the current viewport.

.in -.3i

.in -.5i

.in +.5i

$0 to $9

.in +.3i

The positional parameters given to a complex function (a function

that has been defined with the

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

.in -.3i

.in -.5i

.in +.5i

$*

.in +.3i

All positional parameters given to a complex function.  This

includes parameters that follow after "$9".

.in -.3i

.in -.5i

.in +.5i

$[vp.x]

$[vp.y]

$[vp.width]

$[vp.height]

.in +.3i

Either coordinate or the width or height of the current viewport.

.in -.3i

.in -.5i

.in +.5i

$[desk.width]

$[desk.height]

.in +.3i

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.

.in -.3i

.in -.5i

.in +.5i

$[page.nx]

$[page.ny]

.in +.3i

The current page numbers, by X and Y axes, starting from 0.

.IR page " is equivalent to " area " in the GNOME terminology."

.in -.3i

.in -.5i

.in +.5i

$[w.x]

$[w.y]

$[w.width]

$[w.height]

.in +.3i

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.

.in -.3i

.in -.5i

.in +.5i

$[screen]

.in +.3i

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

multiple screens.

.in -.3i

.in -.5i

.in +.5i

$[fg.cs<n>]

.in -.5i

.in +.5i

$[bg.cs<n>]

.in -.5i

.in +.5i

$[hilight.cs<n>]

.in -.5i

.in +.5i

$[shadow.cs<n>]

.in +.3i

These class of parameters is replaced with the name of the

foreground (fg), background (bg), hilight (hilight) or shadow

(shadow) color that is defined in colorset <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).  Please refer to the man page of the

.B FvwmTheme

module for details about colorsets.  Note that although other

parameters cannot be used in module configuration lines, it is

possible to use this class of parameters.  They can be used

wherever a module expects a color name.  Since the

.B FvwmTheme

module is not running when fvwm first passes through its

configuration file, you may not get the desired results if you use

this in commands like

.EX

Style * HilightFore $[fg.cs0], HilightBack $[bg.cs0]

.EE

.in -.3i

.in -.5i

.in +.5i

$[...]

.in +.3i

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.

.in -.3i

.in -.5i

Some examples can be found in the description of the

.B AddToFunc

command.

.SS THE LIST OF BUILTIN COMMANDS

The commands descriptions below are grouped together in the

following sections.  The sections are hopefully sorted in order of

usefulness to the newcomer.

.EX

- Menu commands

- Miscellaneous commands

- Commands affecting window movement and placement

- Commands for focus and mouse movement

- Commands controlling window state

- Commands for mouse, key and stroke bindings

- The Style command (controlling window styles)

- Other commands controlling window styles

- Commands controlling the virtual desktop

- Commands for user functions and shell commands

- Conditional commands

- Module commands

- Quit, restart and session management commands

- Color gradients

.EE

.SS COMMANDS FOR MENUS

.TP

.BI "AddToMenu " menu-name " [" menu-label " " action "]"

Begins or adds to a menu definition.  Typically a menu definition

looks like this:

.EX

AddToMenu Utilities Utilities Title

 + Xterm           Exec  exec xterm -e tcsh

 + Rxvt            Exec  exec rxvt

 + "Remote Logins" Popup Remote-Logins

 + Top             Exec  exec rxvt -T Top -n \\

                   Top -e top

 + Calculator      Exec  exec xcalc

 + Xman            Exec  exec xman

 + Xmag            Exec  exec xmag

 + emacs           Exec  exec xemacs

 + Mail            MailFunction \\

                   xmh "-font fixed"

 + ""              Nop

 + Modules         Popup Module-Popup

 + ""              Nop

 + Exit Fvwm       Popup Quit-Verify

.EE

The menu could be invoked via

.EX

Mouse 1 R A Menu Utilities Nop

.EE

or

.EX

Mouse 1 R A Popup Utilities

.EE

There is no end-of-menu symbol.  Menus do not have to be defined

in a contiguous region of the

.I .fvwm2rc

file.  The quoted portion in the above examples is the menu label,

which appears in the menu when the user pops it up.  The remaining

portion is a built-in command which should be executed if the user

selects that menu item.  An empty menu-label ("") and the

.B Nop

function can be used to insert a separator into the menu.

The keywords

.IR DynamicPopUpAction " and " DynamicPopDownAction

have a special meaning when used as the name of a menu item.  The

action following the keyword is executed whenever the menu is

popped up or down.  This way you can implement dynamic menus.  It

is even possible to destroy itself with

.B DestroyMenu

and the rebuild from scratch.  When the menu has been destroyed

(unless you used the

.I recreate

option when destroying the menu), do not forget to add the dynamic

action again.

Note: Do not trigger actions that require user interaction. They

will probably fail and may screw up your menus.  See

.B Silent