Fvwm provides both a large virtual desktop and multiple disjoint desktops which can be used separately or together. The virtual desktop allows you to pretend that your video screen is really quite large, and you can scroll around within the desktop. The multiple disjoint desktops allow you to pretend that you really have several screens to work at, but each screen is completely unrelated to the others.
Fvwm provides keyboard accelerators which allow you to perform most window-manager functions, including moving and resizing windows, and operating the window-manager's 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 SloppyFocus and per-window focus methods. SloppyFocus is focus-follows-mouse, but focus is not removed from windows when the mouse leaves a window and enters the root window. When sloppy focus is used as the default focus style, it is nice to make windows in which you do not typically type into (xmag, xman, xgraph, xclock, xbiff, etc) click-to-focus, so that your terminal window doesn't lose focus unnecessarily.
fvwm is copyright 1988 by Evans and Sutherland Computer Corporation, Salt Lake City, Utah, and 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts, All rights reserved. It is also copyright 1993 and 1994 by Robert Nation.
Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Evans & Sutherland and M.I.T. not be used in advertising in publicity pertaining to distribution of the software without specific, written prior permission.
ROBERT NATION, CHARLES HINES, EVANS & SUTHERLAND, AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL EVANS & SUTHERLAND OR M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTUOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Unless the standard defaults files are modified, pressing mouse button 1 in the title or side-bars will begin a move operation on the window. Pressing button 1 in the corner frame pieces will begin 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 "Mouse" configuration parameter below.
The (m by n) size (i.e. number of pages) of the virtual desktops can be changed any time, by using the DeskTopSize built-in command. All virtual desktops must be (are) the same size. The total number of distinct desktops need not be specified, but is limited to approximately 4 billion total. All windows on a range of desktops can be viewed in the Pager, a miniature view of the desktops. The pager is an accessory program, called a module, which is not essential for the window manager to operate. Windows may also be listed, along with their geometries, in a window list, accessible as a pop-up menu, or as a separate window, called the FvwmWinList (another module).
"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:
xterm -geometry +0+0
will always show up 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, then invoking:
xterm -geometry +1000+1000
will place the 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.
There is currently no way to cause a window to map onto a desktop other than the currently active desk, or is there...
A geometry specified as something like:
xterm -geometry -5-5
will generally place 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 that understand standard Xt command line arguments and X resources, like xterm and xfontsel, allow the user to specify the start-up desk on the command line:
xterm -xrm "*Desk:1"
will start an xterm on desk number 1. Not all applications understand this option, however.
You could achieve the same result with the following line in your .Xdefaults file:
XTerm*Desk: 1
Fvwm will set two environment variables which will be 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 rsh to another machine, so $HOSTDISPLAY will also be set and will use a network-ready description of the display. $HOSTDISPLAY will always use 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.
Fvwm has a two special functions for initialization: InitFunction and RestartFunction, which are executed during Initialization and Restarts (respectively). These may be customized in the user's rc file via the AddToFunc facility (described later) to start up modules, xterms, or whatever you'd like have started by fvwm.
Fvwm also has a special exit function: ExitFunction, executed when exiting or restarting before actually quitting or anything else. It could be used to explicitly kill modules, etc.
If both the SHAPE and XPM options are compiled in you will get shaped color icons, which are very spiffy.
Modules MUST be spawned by fvwm so that it can set up two pipes for fvwm and the module to communicate with. The pipes will already be open for the module when it starts and the file descriptors for the pipes are provided as command line arguments.
Modules can be spawned during fvwm at any time during the X session by use of the Module 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 will close the communication pipes and wait 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 will exit 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 .fvwm2rc setup file. Certain auxiliary information is also transmitted, as in the sample module FvwmButtons. The FvwmButtons module is documented in its own man page.
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 will allow fvwm to overlook this ICCCM rule.
M4 pre-processing is handled by a module in fvwm-2.0. To get more details, try man FvwmM4. In short, if you want fvwm to parse your files with m4, then replace the word "Read" with "FvwmM4" in your .fvwm2rc file (if it appears at all), and start fvwm with the command
fvwm -cmd "FvwmM4 .fvwm2rc"
Cpp is the C-language pre-processor. fvwm-2.0 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".
Windows can be automatically raised when it receives focus, or some number of milliseconds after it receives focus, by using the auto-raise module, FvwmAuto.
Lines beginning with '#' will be ignored by fvwm. Lines starting with '*' are expected to contain module configuration commands (rather than configuration commands for fvwm itself).
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.
Example: the .fvwm2rc file contains the line "HelpMe". Fvwm will look for a built-in command called "HelpMe", and will fail. Next it will look for a user-defined complex function called "HelpMe". If no such user defined function exists, Fvwm will try to execute a module called "HelpMe".
In previous versions of fvwm, quoting was critical and irrational in the .fvwmrc file. As of fvwm-2, most of this has been cleared up. 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: Popup Window-Ops, but if you replace the dash with a space, then you need quotes: Popup "Window Ops".
Buttons are drawn in the order of definition, beginning with the most recent ButtonStyle, followed by those added with AddButtonStyle. To clear the button style stack, change style flags, or for descriptions of available styles and flags, see the ButtonStyle command. Examples:
ButtonStyle 1 Pixmap led.xpm -- Top Left
ButtonStyle 1 ActiveDown HGradient 8 grey black
ButtonStyle All -- UseTitleStyle
AddButtonStyle 1 ActiveUp (Pixmap a.xpm) ActiveDown (Pixmap b.xpm -- Top)
AddButtonStyle 1 Vector 4 50x30@1 70x70@0 30x70@0 50x30@1
Initially for this example all button states are set to a pixmap. The second line replaces the ActiveDown state with a gradient (it overrides the pixmap assigned to it in the line before, which assigned the same style to every state). Then, the UseTitleStyle flag is set for all buttons, which causes fvwm to draw any styles set with TitleStyle before drawing the buttons. Finally, AddButtonStyle is used to place additional pixmaps for both ActiveUp and ActiveDown states and a Vector button style is drawn on top of all state.
Title bars are drawn in the order of definition, beginning with the most recent TitleStyle, followed by those added with AddTitleStyle. To clear the title style stack, change style flags, or for the descriptions of available styles and flags, see the TitleStyle and ButtonStyle commands.
Created decors start out exactly like the default fvwm decor without any style definitions. A given decor may be applied to a set of windows with the UseDecor option of the Style command. Modifying an existing decor will affect windows which are currently assigned to it.
AddToDecor is similar in usage to the AddToMenu and AddToFunc commands, except that menus and functions are replaced by ButtonStyle, AddButtonStyle, TitleStyle, AddTitleStyle, BorderStyle, HilightColor and WindowFont commands. Decors created with AddToDecor can be manipulated with ChangeDecor, DestroyDecor, UpdateDecor, and the UseDecor Style option.
The following example creates a decor and style, both named "flatness." Despite having the same name, they are distinct entities:
AddToDecor flatness
+ ButtonStyle All ActiveUp (-- flat) Inactive (-- flat)
+ TitleStyle -- flat
+ BorderStyle -- HiddenHandles NoInset
+ HilightColor white navy
Style "flatness" UseDecor flatness,Color white/grey40,HandleWidth 4
Style "xterm" UseStyle flatness
An existing window's decor may be reassigned with ChangeDecor, or a Style command followed by a Recapture. The decorations of all windows or of a specific decor can be updated with UpdateDecor (useful after decorations are modified; changing Style options requires a Recapture instead). A decor can be destroyed with DestroyDecor.
AddToMenu Utilities "Utilities" Title
+ "Xterm" Exec xterm -e tcsh
+ "Rxvt" Exec rxvt
+ "Remote Logins" Popup Remote-Logins
+ "Top" Exec rxvt -T Top -n Top -e top
+ "Calculator" Exec xcalc
+ "Xman" Exec xman
+ "Xmag" Exec xmag
+ "emacs" Exec xemacs
+ "Mail" MailFunction xmh "-font fixed"
+ "" Nop
+ "Modules" Popup Module-Popup
+ "" Nop
+ "Exit Fvwm" Popup Quit-Verify
The menu could be invoked via
Mouse 1 R A Menu Utilities Nop
or
Mouse 1 R A Popup Utilities
There is no end-of-menu symbol. Menus do not have to be defined in a contiguous region of the .fvwm2rc file. The quoted portion in the above examples is the menu-label, which will appear 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 Nop function can be used to insert a separator into the menu.
If the menu-label contains a sub-string which is set off by stars, then the text between the stars is expected to be the name of an xpm-icon or bitmap-file to insert in the menu. For example
+ "Calculator*xcalc.xpm*" Exec xcalc
inserts a menu item labeled "calculator" with a picture of a calculator above it. The following:
+ "*xcalc.xpm*" Exec xcalc
Omits the "Calculator" label, but leaves the picture.
If the menu-label contains a sub-string which is set off by percent signs, then the text between the percent signs is expected to be the name of an xpm-icon or bitmap-file to insert to the left of the menu label. For example
+ "Calculator%xcalc.xpm%" Exec xcalc
inserts a menu item labeled "calculator" with a picture of a calculator to the left. The following:
+ "%xcalc.xpm%" Exec xcalc
Omits the "Calculator" label, but leaves the picture. The pictures used with this feature should be small (perhaps 16x16).
AddToFunc Move-or-Raise "I" Raise
+ "M" Move
+ "D" Lower
The function name is Move-or-Raise, and could be invoked from a menu or a mouse binding or key binding:
Mouse 1 TS A Move-or-Raise
The quoted portion of the function tells what kind of action will trigger the command which follows it. "I" stands for Immediate, and is executed as soon as the function is invoked. "M" stands for Motion, i.e. if the user starts moving the mouse. "C" stands for Click, i.e., if the user presses and releases the mouse in a short period of time (ClickTime milliseconds). "D" stands for double-click. The action "I" will cause an action to be performed on the button-press, if the function is invoked with prior knowledge of which window to act on.
The special symbols $w and $0 through $9 are available in the ComplexFunctions or Macros, or whatever you want to call them. Within a macro, $w is expanded to the window-id (expressed in hex, i.e. 0x10023c) of the window for which the macro was called. $0 though $9 are the arguments to the macro, so if you call
Key F10 R A Function MailFunction xmh "-font fixed"
and MailFunction is
AddToFunc MailFunction "I" Next [$0] Iconify -1
+ "I" Next [$0] focus
+ "I" None [$0] Exec $0 $1
Then the last line of the function becomes
+ "I" None [xmh] Exec xmh -font fixed
The expansion is performed as the function is executed, so you can use the same function with all sorts of different arguments. I could use
Key F11 R A Function MailFunction zmail "-bg pink"
in the same .fvwm2rc, if I wanted. An example of using $w is:
AddToFunc PrintFunction "I" Raise
+ "I" Exec xdpr -id $w
Note that $$ is expanded to $.
style is a subset of the available ButtonStyles, and can only be TiledPixmap (uniform pixmaps which match the bevel colors work best with this). If an "!" is prefixed to any flag, flag behavior is negated. If style is not specified, then one can change flags without resetting the style.
The "HiddenHandles" flag hides the corner handle dividing lines on windows with handles (this option has no effect for NoHandle windows). By default, HiddenHandles is disabled.
The "NoInset" flag supplements HiddenHandles. If given, the inner bevel around the window frame is not drawn. If HiddenHandles is not specified, this flag has no effect.
To decorate the active and inactive window borders with a textured pixmap, one might specify:
BorderStyle Active TiledPixmap marble.xpm
BorderStyle Inactive TiledPixmap granite.xpm
BorderStyle Active -- HiddenHandles NoInset
To clear the style for both states:
BorderStyle Simple
To clear for a single state:
BorderStyle Active Simple
To unset a flag for a given state:
BorderStyle Inactive -- !NoInset
Title-bar buttons can inherit the border style with the UseBorderStyle flag (see ButtonStyle).
state refers to which button state should be set. Button states are defined as follows: "ActiveUp" and "ActiveDown" refer to the unpressed and pressed states for buttons on active windows; while the "Inactive" state denotes buttons on inactive windows.
If state is ActiveUp, ActiveDown, or Inactive, that particular button state is set. If state is omitted, every state is set. Specifying a style destroys the current style (use AddButtonStyle to avoid this).
If style is omitted, then state-dependent flags can be set for the primary button style without destroying the current style. Examples (each line should be considered independent):
ButtonStyle Left -- flat
ButtonStyle All ActiveUp (-- flat) Inactive (-- flat)
The first line sets every state of the left buttons to flat, while the second sets only the ActiveUp and Inactive states of every button to flat (only flags are changed; the buttons' individual styles are not changed).
If you want to reset all buttons to their defaults:
ButtonStyle Reset
To reset the ActiveUp button state of button 1 to the default:
ButtonStyle 1 ActiveUp Default
To reset all button states of button 1 to the default of button number 2:
ButtonStyle 1 Default 2
For any given button, multiple state definitions can be given on one line by enclosing the style and flags in parentheses. If only one definition per line is given the parentheses can be omitted.
flags affect the specified state. If an "!" is prefixed to any flag, its behavior is negated. The available state-dependent flags for all styles are described here (the next ButtonStyle entry deals with state-independent flags).
"Raised" causes a raised relief pattern to be drawn.
"Sunk" causes a sunken relief pattern to be drawn.
"Flat" inhibits the relief pattern from being drawn.
"UseTitleStyle" causes the given button state to render the current title style before rendering the button's own styles. The Raised, Flat, and Sunk TitleStyle flags are ignored since they are redundant in this context.
"UseBorderStyle" causes the button to inherit the decorated BorderStyle options.
Raised, Sunk, and Flat are mutually exclusive, and can be specified for the initial ButtonStyle only. UseTitleStyle and UseBorderStyle are also mutually exclusive (both can be off however). The default is Raised with both UseBorderStyle and UseTitleStyle left unset.
There is an important note for the ActiveDown state. When a button is pressed, the relief is inverted. Because of this, to obtain a sunken ActiveDown state you must specify the opposite of the desired relief (i.e. to obtain a pressed-in look which is raised, specify Sunk for ActiveDown). This behavior is consistent, but may seem confusing at first.
Button styles are classified as non-destructive, partially destructive, or fully destructive. Non-destructive styles do not affect the image. Partially destructive styles can obscure some or all parts of the underlying image (i.e. Pixmap). Fully destructive styles obscure the entire underlying image (i.e. Solid or one of the gradient styles). Thus, if stacking styles with AddButtonStyle (or AddTitleStyle for title bars), use care in sequencing styles to minimize redraw.
The available styles and their arguments now follow (depending on compilation options, some button styles may be unavailable).
The "Simple" style does nothing. There are no arguments, and this style is an example of a non-destructive button style.
The "Default" style conditionally accepts one argument: a number which specifies the default button number to load. If the style command given is ButtonStyle or AddButtonStyle, the argument is optional (if given, will override the current button). If a command other than ButtonStyle or AddButtonStyle is used, the number must be specified.
The "Solid" style fills the button with a solid color. The relief border color is not affected. The color should be specified as a single argument. This style is fully destructive.
The "Vector" style draws a line pattern. Since this is a standard button style, the keyword "Vector" is optional. The specification is a little cumbersome:
ButtonStyle 2 Vector 4 50x30@1 70x70@0 30x70@0 50x30@1
then the button 2 decoration will use a 4-point pattern consisting of a line from (x=50,y=30) to (70,70) in the shadow color (@0), and then to (30,70) in the shadow color, and finally to (50,30) in the highlight color (@1). Is that too confusing? See the sample .fvwm2rc for a few examples. This style is partially destructive.
The "VGradient" and "HGradient" styles denote gradient styles. The H and V prefixes denote both horizontal and vertical directions.
This style has two forms:
The first form specifies a linear gradient. Arguments: total number of colors to allocate (between 2 and 128), the initial color, and the final color.
The second form specifies a nonlinear gradient. Arguments: total number of colors to allocate (between 2 and 128), then the number of segments. For each segment, specify the starting color, percentage to increment, then ending color. Each subsequent segment begins with the color of the last segment. All of the percentages must add up to 100.
Example:
TitleStyle VGradient 16 3 Red 20 Blue 30 Black 50 Grey
The gradient styles are fully destructive.
The "Pixmap" style displays a pixmap. A pixmap should be specified as an argument. For example, the following would give button 2 the same pixmap for both states, and button 4 different pixmaps for the up, down and inactive states.
ButtonStyle 2 Pixmap my_pixmap.xpm
ButtonStyle 4 ActiveUp (Pixmap up.xpm) ActiveDown (Pixmap down.xpm)
ButtonStyle 4 Inactive Pixmap inactive.xpm
The pixmap specification can be given as an absolute or relative pathname (see PixmapPath). If the pixmap cannot be found, the button style reverts to Simple. Flags specific to the Pixmap style are "Left," "Right," "Top," and "Bottom." These can be used to justify the pixmap (default is centered for both directions). Pixmap transparency is used for the color "None." This style is partially destructive.
The "MiniIcon" style draws the window's miniature icon in the button, which is specified with the MiniIcon option of the Style command. This button style accepts no arguments. Example:
Style "*" MiniIcon mini-bx2.xpm
Style "xterm" MiniIcon mini-term.xpm
Style "Emacs" MiniIcon mini-doc.xpm
ButtonStyle 1 MiniIcon
The "TiledPixmap" style accepts a pixmap to be tiled as the button background. One pixmap is specified as an argument. Pixmap transparency is not used. This style is fully destructive.
"MWMButton" can be assigned to the maximize button for windows with the MWMButtons Style option (this is typically assigned to a single button). When the window is maximized, this flag causes the line pattern in Vector button styles to be inverted (this lets you mimic MWM's behavior). This flag is set for the rightmost button by default.
ChangeDecor "CustomDecor1"
If arg1 is non zero then the next desktop number will be the current desktop number plus arg1. Desktop numbers can be negative.
If arg1 is zero then the new desktop number will be arg2.
The number of active desktops is determined dynamically. Only desktops which contain windows or are currently being displayed are active. Desktop numbers must be between 2147483647 and -2147483648 (is that enough?).
DestroyFunc "PrintFunction"
DestroyDecor "CustomDecor1"
DestroyMenu "Utilities"
DestroyModuleConfig FvwmFormFore
DestroyModuleConfig FvwmButtons*
Echo Beginning style defs...
The first parameter tells how milliseconds the pointer must spend on the screen edge before fvwm will move the viewport. This is intended for people who use "EdgeScroll 100 100" but find themselves accidentally flipping pages when they don't want to.
The second parameter tells how many pixels over the edge of the screen a window's edge must move before it actually moves partially off the screen.
Note that, with "EdgeScroll 0 0", it is still possible to move or resize windows across the edge of the current screen. By making the first parameter to EdgeResistance 10000 this type of motion is impossible. With EdgeResistance less than 10000 but greater than 0 moving over pages becomes difficult but not impossible.
If the horizontal and vertical percentages are multiplied by 1000 then scrolling will wrap around at the edge of the desktop. If "EdgeScroll 100000 100000" is used fvwm will scroll by whole pages, wrapping around at the edge of the desktop.
The following example binds function key F1 in the root window, with no modifiers, to the exec function. The program rxvt will be started with an assortment of options.
Key F1 R N Exec rxvt -fg yellow -bg blue -e /bin/tcsh
ExecUseShell
ExecUseShell /usr/local/bin/tcsh
The following example binds mouse button 1 to a function called "Move-or-Raise", whose definition was provided as an example earlier in this man page. After performing this binding fvwm will execute to move-or-raise function whenever button 1 is pressed in a window title-bar.
Mouse 1 T A Function Move-or-Raise
The keyword "Function" may be omitted if "FunctionName" does not coincide with an fvwm built-in function name
GlobalOpts ClickToFocusDoesntPassClick, ClickToFocusDoesntRaise
Note: if the FvwmM4 is used to parse your rc files, then m4 may want to mangle the word "include" which will frequently show up in the IconPath or PixmapPath command. To fix this add undefine(`include') prior to the IconPath command, or better use the '-m4-prefix' option to force all m4 directives to have a prefix of "m4_" (see the FvwmM4 man page).
The following example binds the built in window list to pop up when Alt-Ctrl-Shift-F11 is hit, no matter where the mouse pointer is:
Key F11 A SCM WindowList
Binding a key to a title-bar button will not cause that button to appear unless a mouse binding also exists.
With the optional arguments horizontal and vertical, which are expressed as percentage of a full screen, the user can control the new size of the window. If horizontal is greater than 0 then the horizontal dimension of the window will be set to horizontal*screen_width/100. The vertical resizing is similar. For example, the following will add a title-bar button to switch a window to the full vertical size of the screen:
Mouse 0 4 A Maximize 0 100
The following causes windows to be stretched to the full width:
Mouse 0 4 A Maximize 100 0
This makes a window that is half the screen size in each direction:
Mouse 0 4 A Maximize 50 50
Values larger than 100 can be used with caution.
If the letter "p" is appended to each coordinate (horizontal and/or vertical), then the scroll amount will be measured in pixels.
Modules can be short lived transient programs or, like FvwmButtons, can remain for the duration of the X session. Modules will be terminated by the window manager prior to restarts and quits, if possible. See the introductory section on modules. The keyword "module" may be omitted if ModuleName is distinct from all built-in and function names.
Modifiers is any combination of N for no modifiers, C for control, S for shift, M for Meta, or A for any modifier. For example, a modifier of SM will apply when both the Meta and Shift keys are down. X11 modifiers mod1 through mod5 are represented as the digits 1 through 5.
Function is one of fvwm's built-in functions.
The title bar buttons are numbered with odd numbered buttons on the left side of the title bar and even numbers on the right. Smaller-numbered buttons are displayed toward the outside of the window while larger-numbered buttons appear toward the middle of the window (0 is short for 10). In summary, the buttons are numbered:
1 3 5 7 9 0 8 6 4 2
The highest odd numbered button which has an action bound to it determines the number of buttons drawn on the left side of the title bar. The highest even number determines the number or right side buttons which are drawn. Actions can be bound to either mouse buttons or keyboard keys.
If the optional arguments x and y are provided, then the window will be moved so that its upper left corner is at location (x,y). The units of x and y are percent-of-screen, unless a letter "p" is appended to each coordinate, in which case the location is specified in pixels.
Examples:
Mouse 1 T A Move
Mouse 2 T A Move 10 10
Mouse 3 T A Move 10p 10p
In the first example, an interactive move is indicated. In the second, the window whose title-bar is selected will be moved so that its upper left hand corner is 10 percent of the screen width in from the left of the screen, and 10 percent down from the top. The final example moves the window to coordinate (10,10) pixels.
To bind a previously defined pop-up menu to a key or mouse button:
The following example binds mouse buttons 2 and 3 to a pop-up called "Window Ops". The menu will pop up if the buttons 2 or 3 are pressed in the window frame, side-bar, or title-bar, with no modifiers (none of shift, control, or meta).
Mouse 2 FST N Popup "Window Ops"
Mouse 3 FST N Popup "Window Ops"
Pop-ups can be bound to keys through the use of the Key built in. Pop-ups can be operated without using the mouse by binding to keys and operating via the up arrow, down arrow, and enter keys.
To bind a previously defined pop-up menu to another menu, for use as a sub-menu:
The following example defines a sub menu, "Quit-Verify" and binds it into a main menu, called "RootMenu":
AddToMenu Quit-Verify "Really Quit Fvwm?" Title
+ "Yes, Really Quit" Quit
+ "Restart Fvwm2" Restart fvwm2
+ "Restart Fvwm 1.xx" Restart fvwm
+ "" Nop
+ "No, Don't Quit" Nop
AddToMenu RootMenu "Root Menu" Title
+ "Open an XTerm Window" Popup NewWindowMenu
+ "Login as Root" Exec xterm -fg green -T Root -n Root -e su -
+ "Login as Anyone" Popup AnyoneMenu
+ "Remote Hosts" Popup HostMenu
+ "" Nop
+ "X utilities" Popup Xutils
+ "" Nop
+ "Fvwm Modules" Popup Module-Popup
+ "Fvwm Window Ops" Popup Window-Ops
+ "" Nop
+ "Previous Focus" Prev [*] Focus
+ "Next Focus" Next [*] Focus
+ "" Nop
+ "Refresh screen" Refresh
+ "Recapture screen" Recapture
+ "" Nop
+ "Reset X defaults" Exec xrdb -load $HOME/.Xdefaults
+ "" Nop
+ "" Nop
+ "Quit" Popup Quit-Verify
Popup differs from Menu in that pop-ups do not stay up if the user simply clicks. These are Twm style popup-menus, which are a little hard on the wrist. Menu provides Motif or Microsoft-Windows style menus which will stay up on a click action.
If the optional arguments x and y are provided, then the window will be resized so that its dimensions are x by y). The units of x and y are percent-of-screen, unless a letter "p" is appended to each coordinate, in which case the location is specified in pixels.
This command should not have a trailing ampersand or any command line arguments and should not make use of any environmental variables. Of the following examples, the first two are sure losers, but the third is OK:
Key F1 R N Restart fvwm &
Key F1 R N Restart $(HOME)/bin/fvwm
Key F1 R N Restart /home/nation/bin/fvwm
If the horizontal and vertical percentages are multiplied by 1000 then scrolling will wrap around at the edge of the desktop. If "Scroll 100000 0" is executed over and over fvwm will move to the next desktop page on each execution and will wrap around at the edge of the desktop, so that every page is hit in turn.
If the letter "p" is appended to each coordinate (horizontal and/or vertical), then the scroll amount will be measured in pixels.
windowname can be a window's name, class, or resource string. It can contain the wildcards * and/or ?, which are matched in the usual Unix filename manner. They are searched in the reverse order stated, so that Style commands based on the name override or augment those based on the class, which override or augment those based on the resource string.
Note - windows that have no name (WM_NAME) are given a name of "Untitled", and windows that don't have a class (WM_CLASS, res_class) are given Class = "NoClass" and those that don't have a resource (WM_CLASS, res_name) are given Resource = "NoResource".
options is a comma separated list containing some or all of the keywords BorderWidth, HandleWidth, NoIcon/Icon, MiniIcon, IconBox, NoTitle/Title, NoHandles/Handles, WindowListSkip/WindowListHit, CirculateSkip/CirculateHit, StaysOnTop/StaysPut, Sticky/Slippery, StartIconic/StartNormal, Color, ForeColor, BackColor, StartsOnDesk/StartsAnyWhere, IconTitle/NoIconTitle, MWMButtons/FvwmButtons, MWMBorder/FvwmBorder, MWMDecor/NoDecorHint, MWMFunctions/NoFuncHint, HintOverride/NoOverride, NoButton/Button, OLDecor/NoOLDecor, StickyIcon/SlipperyIcon, SmartPlacement/DumbPlacement, RandomPlacement/ActivePlacement, DecorateTransient/NakedTransient, SkipMapping/ShowMapping, UseDecor, UseStyle, NoPPosition/UsePPosition, Lenience/NoLenience, ClickToFocus/SloppyFocus/MouseFocus|FocusFollowsMouse.
In the above list some options are listed as style-option/opposite-style-option. The opposite-style-option for entries that have them describes the fvwm default behavior and can be used if you want to change the fvwm default behavior.
Icon takes an (optional) unquoted string argument which is the icon bitmap or pixmap to use.
IconBox takes four numeric arguments:
IconBox l t r b
Where l is the left coordinate, t is the top, r is right and b is bottom. Negative coordinates indicate distance from the right or bottom of the screen. The iconbox is a region of the screen will fvwm will attempt to put icons for this window, as long as they do not overlap other icons.
MiniIcon specifies a pixmap to use as the miniature icon for the window. This miniature icon can be drawn in a title-bar button (see ButtonStyle), and can be used by various fvwm modules (FvwmWinList, FvwmIconMan, and FvwmTaskBar). It takes the name of a pixmap as an argument.
StartsOnDesk takes a numeric argument which is the desktop number on which the window should be initially placed. Note that standard Xt programs can also specify this via a resource (e.g. "-xrm '*Desk: 1'").
StaysOnTop makes the window always try to stay on top of the other windows. This might be handy for clocks or mailboxes that you would always like to be visible. If the window is explicitly lowered it will not try to force its way back to the top until it is explicitly raised. StaysPut (the default) allows the window to be obscured and stay that way.
BorderWidth takes a numeric argument which is the width of the border to place the window if it does not have resize-handles.
HandleWidth takes a numeric argument which is the width of the border to place the window if it does have resize-handles.
Button and NoButton take a numeric argument which is the number of the title-bar button which is to be included/omitted.
StickyIcon makes the window sticky when its iconified. It will deiconify on top the active desktop.
MWMButtons makes the Maximize button look pressed-in when the window is maximized. See the MWMButton flag in ButtonStyle for more information.
MWMBorder makes the 3-D bevel more closely match mwm's.
MWMDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use.
MWMFunctions makes fvwm attempt to recognize and respect the mwm prohibited operations hints that applications occasionally use. HintOverride makes fvwm shade out operations that mwm would prohibit, but it lets you perform the operation anyway.
OLDecor makes fvwm attempt to recognize and respect the olwm and olvwm hints that many older XView and OLIT applications use.
Color takes two arguments. The first is the window-label text color and the second is the window decoration's normal background color. The two colors are separated with a slash. If the use of a slash causes problems then the separate ForeColor and BackColor options can be used.
UseDecor accepts one argument: the name of a decor created with AddToDecor. If UseDecor is not specified, the "Default" decor is used. Windows do not actually contain decors, but are always assigned to one. If the decor is later modified with AddToDecor, the changes will be visible for all windows which are assigned to it. The decor for a window can be reassigned with ChangeDecor.
UseStyle takes one arg, which is the name of another style. That way you can have unrelated window names easily inherit similar traits without retyping. For example: 'Style "rxvt" UseStyle "XTerm"'.
SkipMapping tells fvwm not to switch to the desk the window is on when it gets mapped initially (useful with StartsOnDesk).
Lenience instructs fvwm to ignore the convention in the ICCCM which states that if an application sets the input field of the wm_hints structure to False, then it never wants the window manager to give it the input focus. The only application that I know of which needs this is sxpm, and that is a silly bug with a trivial fix and has no overall effect on the program anyway. Rumor is that some older applications have problems too.
ClickToFocus instructs fvwm to give the focus to the window when it is clicked in. The default MouseFocus (or its alias FocusFollowsMouse) tells fvwm to give the window the focus as soon as the pointer enters the window, and take it away when the pointer leaves the window. SloppyFocus is similar, but doesn't give up the focus if the pointer leaves the window to pass over the root window or a ClickToFocus window (unless you click on it, that is), which makes it possible to move the mouse out of the way without losing focus.
NoPPosition instructs fvwm to ignore the PPosition field when adding new windows. Adherence to the PPosition field is required for some applications, but if you don't have one of those its a real headache.
RandomPlacement causes windows which would normally require user placement to be automatically placed in ever-so-slightly random locations. For the best of all possible worlds use both RandomPlacement and SmartPlacement.
SmartPlacement causes windows which would normally require user placement to be automatically placed in a smart location - a location in which they do not overlap any other windows on the screen. If no such position can be found user placement or random placement (if specified) will be used as a fall-back method. For the best of all possible worlds use both RandomPlacement and SmartPlacement.
An example:
# Change default fvwm behavior to no title-bars on windows!
# Also define a default icon.
Style "*" NoTitle,Icon unknown1.xpm, BorderWidth 4,HandleWidth 5
# now, window specific changes:
Style "Fvwm*" NoHandles,Sticky,WindowListSkip,BorderWidth 0
Style "Fvwm Pager" StaysOnTop, BorderWidth 0
Style "*lock" NoHandles,Sticky,StaysOnTop,WindowListSkip
Style "xbiff" Sticky, WindowListSkip
Style "FvwmButtons" NoHandles,Sticky,WindowListSkip
Style "sxpm" NoHandles
Style "makerkit"
# Put title-bars back on xterms only!
Style "xterm" Title, Color black/grey
Style "rxvt" Icon term.xpm
Style "xterm" Icon rterm.xpm
Style "xcalc" Icon xcalc.xpm
Style "xbiff" Icon mail1.xpm
Style "xmh" Icon mail1.xpm, StartsOnDesk 2
Style "xman" Icon xman.xpm
Style "matlab" Icon math4.xpm, StartsOnDesk 3
Style "xmag" Icon magnifying_glass2.xpm
Style "xgraph" Icon graphs.xpm
Style "FvwmButtons" Icon toolbox.xpm
Style "Maker" StartsOnDesk 1
Style "signal" StartsOnDesk 3
Note that all properties for a window will be OR'ed together. In the above example "FvwmPager" gets the property StaysOnTop via an exact window name match but also gets NoHandles, Sticky, and WindowListSkip by a match to "Fvwm*". It will get NoTitle by virtue of a match to "*". If conflicting styles are specified for a window, then the last style specified will be used.
If the NoIcon attribute is set then the specified window will simply disappear when it is iconified. The window can be recovered through the window-list. If Icon is set without an argument then the NoIcon attribute is cleared but no icon is specified. An example which allows only the FvwmPager module icon to exist:
Style "*" NoIcon
Style "Fvwm Pager" Icon
TitleStyle LeftJustified Height 24
If an "!" is prefixed to any flag, its behavior is negated. Valid flags for each state include "Raised," "Flat," and "Sunk" (these are mutually exclusive). The default is Raised. See the note in ButtonStyle regarding the ActiveDown state. Examples:
TitleStyle ActiveUp HGradient 16 navy black
TitleStyle ActiveDown (Solid red -- flat) Inactive (TiledPixmap wood.xpm)
TitleStyle ActiveUp (-- Flat) ActiveDown (-- Raised) Inactive (-- Flat)
This sets the ActiveUp state to a horizontal gradient, the ActiveDown state to solid red, and the Inactive state to a tiled wood pixmap. Finally, ActiveUp is set to look flat, while ActiveDown set to be sunk (the Raised flag for the ActiveDown state causes it to appear Sunk due to relief inversion), and Inactive is set to flat as well. An example which sets flags for all states:
TitleStyle -- flat
For a flattened look:
TitleStyle -- flat
ButtonStyle All ActiveUp (-- flat) Inactive (-- flat)
AddToFunc InitFunction "I" exec xterm -geometry 80x64+0+0
+ "I" Wait xterm
+ "I" Desk 0 2
+ "I" Exec xmh -font fixed -geometry 507x750+0+0
+ "I" Wait xmh
+ "I" Desk 0 0
The above function starts an xterm on the current desk, waits for it to map itself, then switches to desk 2 and starts an xmh. After the xmh window appears control moves to desk 0.
If arg1 is non zero then the next desktop number will be the current desktop number plus arg1. Desktop numbers can be negative.
If arg1 is zero then the new desktop number will be arg2.
If only one argument is given, moves the selected window the the desktop specified as rg1.
WindowId 0x34567890 Raise
WindowId 0x34567890 WarpToWindow 50 50
Mostly this is useful for functions used with the WindowList builtin.
AddToFunc WindowListFunc "I" WindowId $0 Iconify -1
+ "I" WindowId $0 Focus
+ "I" WindowId $0 Raise
+ "I" WindowId $0 WarpToWindow 5p 5p
You can Destroy the builtin WindowListFunc and create your own if these defaults do not suit you.
The options passed to WindowList can be "NoGeometry", "Function <funcname>", "Desk <desknum>", "CurrentDesk", "NoIcons", "Icons", "OnlyIcons", "NoNormal", "Normal", "OnlyNormal", "NoSticky", "Sticky", "OnlySticky", "NoOnTop", "OnTop", "OnlyOnTop", "Unsorted", "UseIconName".
(Note - normal means not iconic, sticky, or ontop)
If you pass in a function via "Function <funcname>", $0 is the window id:
AddToFunc IFunc "I" WindowId $0 Iconify
WindowList Function IFunc, NoSticky, CurrentDesk, NoIcons
If you wanted to use the WindowList as an icon manager, you could invoke the following:
WindowList OnlyIcons, Sticky, OnTop, Geometry
(Note - the "Only" options essentially wipe out all other ones...)
You may need to quit on each screen to quit from the X session completely.
Known bugs can be found in the BUGS file in the distribution, and in the TO-DO list.
Bug reports can be sent to the FVWM mailing list (see the FAQ).