vtwm(1)

๐Ÿ“ฆ
version 5.4.7 ยท 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

๐ŸŽ€ vtwm(1) โ€” Virtual Tab Window Manager for the X Window System ๐ŸŽ€

okay bestie, grab a boba and let's get into it. this is the manual for vtwm, and it's lowkey iconic. no cap. ๐Ÿ’–


โœจ NAME โœจ

vtwm โ€” Virtual Tab Window Manager for the X Window System. that's the whole vibe. slay. ๐Ÿ’…


๐Ÿ’ซ SYNOPSIS ๐Ÿ’ซ

vtwm [ -d display ] [ -f initfile ] [ -m [ m4-options ] ] [ -p ] [ -s ]
[ -v ]

๐ŸŒธ DESCRIPTION ๐ŸŒธ

vtwm is a window manager for the X Window System, and it is genuinely giving main character energy. It provides titlebars, shaped windows, several forms of icon management, user-defined macro functions, click-to-type and pointer-driven keyboard focus, and user-specified key and pointer button bindings. โœจ

This program is usually started by the user's session manager or startup script. When used from xdm(1) or xinit(1) without a session manager, vtwm is frequently executed in the foreground as the last client. When run this way, exiting vtwm causes the session to be terminated (i.e., logged out). so yeah, it's the final boss of your login โ€” quit it and the whole session dips. ๐Ÿ˜ญ

By default, application windows are surrounded by a border with a titlebar at the top. The titlebar contains the window's name, a rectangular area that indicates when the window is receiving keyboard input, and three function boxes known as "titlebar buttons". Pressing pointer Button1 (usually the left-most button unless it has been changed with xmodmap(1)) on any of these titlebar features will invoke the function associated with them.

With the default interface, windows are iconified by clicking (pressing and then immediately releasing) the titlebar button that looks like a dot. Conversely, windows are deiconified by clicking in the associated icon or entry in the icon manager (see the descriptions of the variable ShowIconManager and the function f.showiconmgr in the BINDINGS section). ๐Ÿซถ

Windows are resized by pressing the titlebar button that resembles a group of nested squares, dragging the pointer over the edge that is to be moved, and releasing the pointer when the window is the desired size. Similarly, windows are moved by pressing in the title or highlight area, dragging it to the new location, and then releasing when the window is in the desired position. Just clicking in the title or highlight area raises the window without moving it.

Pressing the titlebar button with the down arrow in it brings up a menu with many other functions that may be applied to the window. menu drop? we love to see it. ๐Ÿ“

When new windows are created, vtwm will honor any size and location information requested by the user (usually through -geometry command line argument or X11 resources for the individual applications). With the default configuration, Clicking pointer Button1 will position the window at the current position and give it the default size. Pressing pointer Button2 (usually the middle pointer button) and dragging the window will give the window its current position but allow the sides to be resized as described above. Clicking pointer Button3 (usually the right pointer button) will give the window its current position but attempt to make it long enough to touch the bottom of the screen.

The default behavior during these operations is to represent the window with an outline of the client window and its titlebar, lines crossing within the client window. Alternatively, vtwm may be configured to draw the window completely, but it is not recommended unless yours is a fast system.

โš ๏ธ bestie, full draw is cute but only if your machine is fast. no cap.

๐Ÿฆ‹ THE VIRTUAL DESKTOP ๐Ÿฆ‹

vtwm is based upon the twm(1) window manager, but adds extra functionality in the form of a virtual desktop. The virtual desktop is an area larger than the physical screen. The real screen is considered to be a window onto portions of the virtual desktop showing whatever windows are present in that area of the desktop. To help navigate around the desktop, vtwm creates a new window, of the name VTWM Desktop, which shows the entire desktop using a small scale. In the Virtual Desktop window, all windows that exist are displayed and various options are provided to recognize the identity of the different windows (see the descriptions of the variables DesktopDisplayBackground, DesktopDisplayForeground, DesktopDisplayBorder and VirtualDesktopFont). ๐ŸŒˆ

To provide a consistent workspace, the option is provided of nailing windows onto the real screen. When a window is nailed, it is considered stuck to the real screen no matter what part of the desktop is currently being displayed. nailed down? periodt. ๐Ÿ“Œ

Normally, a few standard utilities are nailed down: the icon manager, the desktop view, a load average chart, a clock, and a mail notifier. The f.nail (or its alias, f.stick) function can be used to change the nailed status of any window; see the BINDINGS section for details.

The root window of the display is unchanged by this program and utilities such as xsetroot(1) will continue to work unmodified. ๐Ÿ’œ


๐Ÿ’… OPTIONS ๐Ÿ’…

vtwm accepts the following command line options:

  • -d display โ€” This option specifies the X server to use. like, which display you are pulling up on. ๐Ÿ–ฅ๏ธ
  • -f [initfile] โ€” This option specifies the name of the startup file to use. By default, vtwm will look in the user's home directory for files named .vtwmrc.N, .vtwmrc, .twmrc.N, or .twmrc (where 'N' is a screen number). It also looks for system-wide default files; see the CUSTOMIZATION section below for details. If initfile is not provided, this specifies that vtwm should disregard any startup files it finds, and use only the defaults that are compiled in (intended for testing compiled-in defaults). no initfile? it is giving "ignore all your pretty configs and run the baked-in defaults." ๐Ÿ™ˆ
  • -m [options] โ€” This option causes vtwm to preprocess the startup file using the m4(1) macro processor. The options will be passed verbatim to m4 along with those symbols that vtwm declares. Note that options itself should be quoted, to prevent unwanted processing that may occur by the shell, etc. quote it, bestie, or the shell will start acting up. ๐Ÿ’€
  • -p โ€” This option indicates that vtwm should attempt to write it's PID to $HOME/vtwm.pid on startup, and delete that file on shutdown. This file may be useful as a lock file, or for determining the correct vtwm process for a particular user. If the file cannot be written on startup, a bell will sound, but vtwm will continue. ๐Ÿ””
  • -s โ€” This option indicates that only the default screen (as specified by the -d option or by the DISPLAY environment variable) should be managed. By default, vtwm will attempt to manage all screens on the display. one screen only? lowkey focused. ๐ŸŽฏ
  • -v โ€” This option indicates that vtwm should print messages to the stderr device when an unexpected event occurs. This can be useful for debugging applications, but may be distracting in regular use. ๐Ÿ‘€

๐ŸŒˆ CUSTOMIZATION ๐ŸŒˆ

Much of vtwm's appearance and behavior can be controlled by providing a startup file in one of the following locations (searched in order for each screen being managed when vtwm begins):

  • $HOME/.vtwmrc.screennumber โ€” The screennumber is a small positive number (e.g., 0, 1, etc.) representing the screen number (e.g., the last number in the DISPLAY environment variable host:displaynum.screennum) that would be used to contact that screen of the display. This is intended for displays with multiple screens of differing visual types. ๐ŸŒธ
  • $HOME/.vtwmrc โ€” This is the usual name for an individual user's startup file. ๐Ÿ’–
  • $VTWMDIR/twm/system.vtwmrc โ€” If neither of the preceding files are found, vtwm will look in this file for a default configuration. Note that the variable is defined only in the Makefile, and is often set and tailored by the site administrator to provide convenient menus or familiar bindings for novice users. ๐Ÿ‘‘
  • $HOME/.twmrc.screennumber
  • $HOME/.twmrc
  • $VTWMDIR/twm/system.twmrc โ€” When none of the .vtwmrc files can be found, vtwm reverts to acting like twm(1), and searches for these three .twmrc variants. Note that the variable is defined only in the Makefile.

This search algorithm allows both twm(1) and vtwm to coexist peacefully at an installation. Since vtwm is a superset of twm(1), it can even used to replace the latter, and users who have only a .twmrc-style file should not notice much difference.

If no startup files are found, or if vtwm is told to ignore them, vtwm will use built-in defaults as described in the DESCRIPTION section above, though the system.vtwmrc file, if re-configured before the build, may intervene. The only X11 resource used by vtwm is bitmapFilePath for a colon-separated list of directories to search when looking for bitmap and pixmap files (for more information, see the Athena Widgets manual and xrdb(1)).

vtwm startup files are logically broken up into three types of specifications: Variables, Bindings, Menus.

The Variables section must come first and is used to describe the fonts, colors, cursors, border widths, icon and window placement, highlighting, autoraising, layout of titles, warping, and use of the icon manager.

The Bindings section usually comes second and is used to specify the functions that should be to be invoked when keyboard and pointer buttons are pressed in windows, icons, titles, and frames.

The Menus section gives any user-defined menus (containing functions to be invoked or commands to be executed).

Variable names and keywords are case-insensitive. Strings must be surrounded by double quote characters (e.g., "blue") and are case-sensitive. A sharp sign ('#') outside of a string causes the remainder of the line in which the character appears to be treated as a comment.

๐Ÿ”ฎ M4 PREPROCESSING ๐Ÿ”ฎ

okay so this is genuinely one of the most powerful glow-ups vtwm got, as of version 5.4.6: it can use m4(1) to pre-process its startup files. bestie, when vtwm is started with -m, it opens a file for input like we described earlier, but runs that file through m4 before parsing it. so you can use m4 macros to do stuff at runtime, and it makes juggling a million different displays etc. so much easier. ๐Ÿ’…

for example, say you want the lower-right chunk of the screen to be your IconRegion โ€” you can use m4 directives plus the pre-defined symbols to compute the region you actually want:

define(IRegion, translit(eval(WIDTH/3)*eval(HEIGHT/2)+eval(WIDTH-WIDTH/3)-0, *, x))
IconRegion  "IRegion" SOUTH EAST 75 25

that defines the lower half, and the right-hand third of the screen. the symbols WIDTH and HEIGHT are calculated by vtwm specifically for m4 to use. here are all the symbols vtwm pre-defines for you (no cap, it's a lot):

  • SERVERHOST โ€” set to the name of the machine running the X server.
  • CLIENTHOST โ€” the machine running the X clients (i.e., "vtwm", "xterm", etc.).
  • HOSTNAME โ€” the canonical hostname running the clients (i.e., a fully-qualified version of CLIENTHOST).
  • USER โ€” the name of the user running the program. gotten from the environment.
  • HOME โ€” the user's home directory. also gotten from the environment.
  • VERSION โ€” the X major protocol version. as seen by ProtocolVersion().
  • REVISION โ€” the X minor protocol revision. as seen by ProtocolRevision().
  • VENDOR โ€” the vendor of your X server (i.e., "MIT X Consortium").
  • RELEASE โ€” the release number of your X server. for MIT X11R5, this is "5".
  • WIDTH โ€” the width of your display in pixels.
  • HEIGHT โ€” the height of your display in pixels.
  • X_RESOLUTION โ€” the X resolution of your display in pixels per meter.
  • Y_RESOLUTION โ€” the Y resolution of your display in pixels per meter.
  • PLANES โ€” the number of bit planes your display supports in the default root window.
  • BITS_PER_RGB โ€” the number of significant bits in an RGB color. (log base 2 of the number of distinct colors that can be created. this is often different from the number of colors that can be displayed at once.)
  • TWM_TYPE โ€” tells which twm derivative is running. it will always be set to "vtwm" in this program. super useful for protecting parts of your startup file that twm proper won't understand (like VirtualDesktop) so it's still usable with other twm-based programs. ๐Ÿซถ
  • CLASS โ€” your visual class. returns one of "StaticGray", "GrayScale", "StaticColor", "PseudoColor", "TrueColor", "DirectColor", or, if it can't figure out what you have, "NonStandard".
  • COLOR โ€” either "Yes" or "No". this is just a wrapper around the above definition. returns "Yes" on "*Color", and "No" on "StaticGray" and "GrayScale".
  • I18N โ€” either "Yes" or "No" depending on whether support for internationalization has been compiled in.
  • XPM โ€” either "Yes" or "No" depending on whether support for pixmap image files has been compiled in.
  • SOUND โ€” either "Yes" or "No" depending on whether support for sound has been compiled in.
  • REGEX โ€” either "Yes" or "No" depending on whether support for regular expressions ("RE"s) has been compiled in.
heads up bestie: any symbols you pass to m4 on the command line that conflict with these will not be anticipated or dealt with by vtwm. you are entirely at the mercy of your particular m4. ๐Ÿ˜ญ
also note: if vtwm's preparation for executing m4 fails, the startup file gets processed normally, and it will choke on the first m4 macro it encounters. ๐Ÿ’€

finally, be aware that m4 preprocessing can cause things often found in startup files to break. for example, quotes and backquotes in shell commands will be badly messed up by m4's own internal quoting mechanism. this particular problem can be worked around by placing changequote(,) at the top of your startup file. โœจ

invoking vtwm with both the -m and -v options will print the m4 command with all symbols expanded.


๐Ÿ’œ VARIABLES ๐Ÿ’œ

so many of the aspects of vtwm's user interface are controlled by variables that you set in your startup file. some of them are basically just vibes โ€” enabled or disabled just by the presence of a particular keyword. others actually want keywords, numbers, strings, or lists of all of these. it's giving flexibility. ๐ŸŒˆ

lists are surrounded by braces and are usually separated by whitespace or a newline. for example:

AutoRaise { "emacs" "VTWM*" "x*clock" "Xmh" "XTerm" }

or:

AutoRaise
{
    "emacs"
    "VTWM*"
    "x*clock"
    "Xmh"
    "XTerm"
}

when a variable containing a list of strings representing windows gets searched (e.g., to decide whether or not to enable autoraise like above), a string has to be a case-sensitive match to the window's name (given by the WM_NAME window property), or the class name or class class (both given by the WM_CLASS window property). the example up there would enable autoraise on windows named "emacs", all vtwm-specific windows, any clocks installed whose name starts with an 'x' (asclock will not autoraise, fyi), and all xmh and xterm windows (which are of class "XTerm" and "Xmh", respectively). see the WILDCARDS section for what those asterisks ('*') actually mean. ๐Ÿ‘‘

string arguments interpreted as filenames (peep the Pixmaps, Cursors, and IconDirectory variables below) will prepend the user's directory (specified by the HOME environment variable) if the first character is a tilde ('~'). if instead the first character is a colon (':'), the name is assumed to refer to one of the internal bitmaps used to create 2D titlebar buttons, the 2D icon manager button, and the 2D menu pull-right icon. and finally, if the first five characters are :xpm:, the name is assumed to refer to one of the built-in pixmaps that can be used to create 3D titlebar buttons, the 3D icon manager button, and the 3D menu pull-right icon. see the IMAGE AND AUDIO FORMATS section for further details. ๐ŸŽ€

the following variables may be specified in the vtwm startup file. lists of window names are indicated by win-list, and optional arguments are shown in square brackets. any default values are based on the distributed system.vtwmrc files, and if none is mentioned, the default setting is "off", "disabled", or "none".

  • AppletRegion geomstr vgrav hgrav hgrid vgrid { win-list } โ€” this variable specifies an area on the root window where the windows listed in win-list get placed. the geomstr is a quoted string containing a standard geometry specification for the region size and location. if more than one AppletRegion is specified, windows will be put into succeeding regions that have the window listed, once the first is full. the vgrav argument should be either North or South and controls whether windows are first filled in from the top or bottom of the region. similarly, the hgrav argument should be either East or West and controls whether windows should be filled in from the left or right. windows are laid out in a grid with cells hgrid pixels wide and vgrid pixels high. note that the smallest dimension of the region must be at least the size of the largest window in it, including frame and titlebar, in the same direction. this variable exists to simplify management of all those little tool applications like xcb(1), xbiff(1), xload(1), etc. that you use regularly. ๐Ÿ“
  • AutoPan N โ€” lets the screen automatically pan by N% of a real screen when the pointer approaches the edge of the screen. the pan goes in the direction of the edge approached. the default is 100, effectively "paging" across the virtual desktop. ๐Ÿฆ‹
  • AutoPanBorderWidth pixels โ€” if AutoPan is turned on, the screen gets panned when the pointer goes within the specified number of pixels of the real screen's border. the default value is 5.
  • AutoPanExtraWarp pixels โ€” if AutoPan is turned on and NaturalAutopanBehavior is turned off, this variable says how far, in pixels, you want the pointer to move away from the inner edge of the autopan border when autopanning. the default value is 2 pixels.
  • AutoPanWarpWithRespectToRealScreen N โ€” with this turned on, the pointer gets warped by N% as many pixels on the real screen as the screen is scrolled, or by (AutoPanBorderWidth + AutoPanExtraWarp) pixels, whichever is greater. see NaturalAutopanBehavior for a more thorough discussion of this and some recommended settings. โœจ
  • AutoRaise [{ win-list }] โ€” specifies a list of windows (all windows if win-list is omitted) to be automatically raised whenever the pointer has come to rest in a window for the amount of time specified by the RaiseDelay variable. this action can be interactively enabled or disabled on individual windows using the function f.autoraise. ๐Ÿ’…
  • AutoRaiseDelay milliseconds โ€” a synonym for RaiseDelay.
  • AutoRelativeResize โ€” indicates that dragging out a window size (either when initially sizing the window with pointer Button2 or when resizing it) should not wait until the pointer has crossed the window edges. instead, moving the pointer automatically causes the nearest edge or edges to move by the same amount. this lets you resize windows that extend off the edge of the screen. if the pointer is in the center of the window, or if the resize was begun by pressing a titlebar button, vtwm will still wait for the pointer to cross a window edge (to prevent accidents). this option is particularly useful for people who like the press-drag-release method of sweeping out window sizes. ๐Ÿซถ
  • BeNiceToColormap โ€” specifies that stippled lines be used for the bevel colors when any of the 3D variables are set, to conserve on colormap allocations. so thoughtful of it honestly. ๐Ÿ’–

BorderBevelWidth</p> pixels

okay so this one tells vtwm to give your window borders that 3D look ๐Ÿ‘‘ and pixels is literally just the width of the bevel, in pixels. The 3D border gets its color from BorderTileBackground, and if NoHighlight is not selected, then the border of the Focus window is BorderColor instead. Default? Depends on your build bestie: 0 if vtwm is built with 2D features, or 2 when it's built with 3D features โœจ

BorderColor</p> string [{ wincolorlist }]

This sets the default color of the border wrapped around all non-iconified windows ๐ŸŽ€ and heads up โ€” it can only be given inside a Color or Monochrome list. The optional wincolorlist lets you hand out window-and-color name pairs so different kinds of windows get their own border colors. It's giving customization, fr fr:

BorderColor    "gray50"
{
    "XTerm"    "red"
    "xmh"      "green"
}

The default is "gray70".

BorderTileBackground</p> string [{ wincolorlist }]

This one is the default background color in the gray pattern used for unhighlighted borders (only if NoHighlight hasn't been set, iykyk) and again it may only live inside a Color or Monochrome list. The optional wincolorlist lets you do per-window colors ๐Ÿ’… The default is "gray60".

BorderTileForeground</p> string [{ wincolorlist }]

Same situation but for the foreground color in that gray pattern for unhighlighted borders (again, only if NoHighlight hasn't been set). Also only inside a Color or Monochrome list, and the optional wincolorlist allows per-window colors ๐Ÿฆ‹ The default is "gray60".

BorderWidth</p> pixels

Sets the width in pixels of the border around all client window frames โ€” but only if ClientBorderWidth hasn't been specified. This value also gets used to set the border size of windows that vtwm creates itself (like the icon manager ๐Ÿ‘€). The default is 2 if vtwm is built with 2D features, or 6 when it's built with 3D features. Big 3D energy ๐ŸŒˆ

ButtonBevelWidth</p> pixels

Tells vtwm to use 3D-looking window buttons (yes, the buttons deserve their moment). It specifies the width in pixels of the bevel. The default is 0 if vtwm is built with 2D features, or 1 when vtwm is built with 3D features โœจ

ButtonIndent</p> pixels

This is the size of titlebar buttons, expressed as a difference from the titlebar font height โ€” which normally means titlebar buttons will shrink (built-in images) or get cropped (external images) accordingly ๐Ÿ˜ญ A negative value is accepted though, and it means titlebar buttons should be larger than the titlebar font. Setting this to a negated FramePadding value, with TitleButtonBorderWidth set to 0, makes titlebar buttons as tall and wide as possible ๐Ÿ‘‘

The default is 0 if vtwm is built with with 2D features, or -2 when vtwm is built with 3D features.

ButtonColorIsFrame</p>

This says the titlebar buttons will be the same color as the window frame ๐Ÿ’– It is set by default if vtwm is built with 3D features.

ClearBevelContrast</p> contrast

Indicates to vtwm how to calculate the clear bevel color for 3D items โœจ The value is a compressed to the range 0 and 100. The formula used is:

clear.{RGB} = (65535 - color.{RGB}) * (contrast / 100)

The default is 40 if vtwm is built with 3D features.

ClientBorderWidth</p>

This variable indicates that the width of a window's frame should be set to the border width as specified by the client, rather than to the value of BorderWidth. But โ€” plot twist ๐Ÿ™ˆ โ€” if BorderBevelWidth is non-zero, this variable is ignored.

Color</p> { colors-list }

This specifies a whole list of color assignments to be made if the default display is capable of displaying more than simple black and white ๐ŸŒˆ The colors-list is made up of the following color variables and their values: DefaultBackground, DefaultForeground, MenuBackground, MenuForeground, MenuTitleBackground, MenuTitleForeground, and MenuShadowColor.

The following color variables may also be given a list of window and color name pairs so you can do per-window colors (see BorderColor for the details, bestie): BorderColor, DesktopDisplayForeground, DesktopDisplayBackground, RealScreenForeground, RealScreenBackground, VirtualForeground, VirtualBackground, DekstopDisplayBorder, IconManagerHighlight, BorderTitleBackground, BorderTitleForeground, TitleBackground, TitleForeground, IconBackground, IconForeground, IconBorderColor, IconManagerBackground, and IconManagerForeground.

Example time ๐ŸŽ€:

Color
{
    MenuBackground     "gray50"
    MenuForeground     "blue"
    BorderColor        "red"
    {
        "XTerm"        "yellow"
    }
    TitleForeground    "yellow"
    TitleBackground    "blue"
}

All of these color variables may also be specified for the Monochrome variable, which means the same initialization file can be used on both color and monochrome displays. So versatile, we love her ๐Ÿ’…

ConstrainedMoveTime</p> milliseconds

This is the length of time between button clicks needed to begin a constrained move operation. Double clicking within this amount of time when invoking f.move will cause the window to only be moved in a horizontal or vertical direction ๐Ÿ‘€ Setting this value to 0 will disable constrained moves entirely. The default is 400 milliseconds.

Cursors</p> { cursor-list }

This is the glyphs vtwm should use for the various pointer cursors โœจ Each cursor may be defined either from the cursor font, or from two bitmap files.

Shapes from the cursor font can be specified directly like this:

cursorname    "string"

where cursorname is one of the cursor names listed below, and string is the name of a glyph as found in the file /usr/include/X11/cursorfont.h (without the "XC_" prefix, okay?).

If the cursor is to be defined from bitmap files, you use this syntax instead:

cursorname    "image"    "mask"

where image and mask specify the names of files containing the glyph image and mask in bitmap(1) form. The bitmap files are located in the same manner as icon bitmap files ๐Ÿฆ‹

Here's the example showing the default cursor definitions, iconic behavior honestly:

Cursors
{
    Frame      "top_left_arrow"
    Title      "top_left_arrow"
    Icon       "top_left_arrow"
    IconMgr    "top_left_arrow"
    Move       "fleur"
    Resize     "fleur"
    Menu       "sb_left_arrow"
    Button     "hand2"
    Wait       "watch"
    Select     "dot"
    Destroy    "pirate"
    Door       "exchange"
    Virtual    "rtl_logo"
    Desktop    "dotbox"
}

DarkBevelContrast</p> contrast

Indicates to vtwm has to calculate the dark bevel color for 3D items ๐ŸŒธ The value is a comprised between 0 and 100. The formula used is:

dark.{RGB} = color.{RGB} * ((100 - contrast) / 100)

The default is 40 if vtwm is built with 3D features.

DecorateTransients</p>

This variable indicates that transient windows (those containing a WM_TRANSIENT_FOR property) should have titlebars ๐Ÿ‘‘ By default though, transients are not reparented. So if you want them dolled up, you gotta say so.

DefaultBackground</p> string

This specifies the background color used for sizing and information windows. The default is "maroon" for color displays, or "gray50" for monochrome displays ๐ŸŽ€

DefaultForeground</p> string

This specifies the foreground color used for sizing and information windows. The default is "gray85" โœจ

DeiconifyToScreen</p>

When deiconifying a window, by default the window gets placed at its previous geometry in the virtual desktop. With this variable set, vtwm makes sure the window will be placed somewhere on the real screen ๐Ÿฆ‹ lowkey so useful, never lose a window again.

DesktopDisplayBackground</p> color [{ win-list }]

This sets the backgrounds of the little windows inside the Virtual Desktop window, AND it sets the backgrounds of menu entries in the VTWM Windows menu โ€” unless you specify OldFashionedVtwmWindowsMenu ๐Ÿ‘€ The default color is used for the default background of windows not named in the list. The optional win-list is a list of window names and colors, like:

DesktopDisplayBackground    "purple"
{
    "zwgc"                  "green"
}

The default is "gray60".

DesktopDisplayBorder</p> color [{ win-list }]

This sets the border color in the virtual desktop representation window to color ๐Ÿ’œ The win-list is in the same format as TitleForeground and other similar variables.

DesktopDisplayBorder    "black"
{
    "zwgc"              "green"
}

The default is "black".

DesktopDisplayForeground</p> color [{ win-list }]

If both this and the VirtualDesktopFont variable are set, then the names of the windows will be written in the window representations shown in the desktop โœจ This entry also sets foreground colors for entries in the VTWM Windows menu. The format of this variable is the same as that used for DesktopDisplayBackground. The default is "gray85".

DontDeiconifyTransients</p>

This variable sees that iconified transient windows of an iconified parent window aren't deiconified when that parent is โ€” thus preserving their state ๐Ÿ’… Default behavior, for contrast, is to deiconify all transient subwindows of the ancestor window when it is deiconified. So this is the one that says "no bestie, leave them napping."

DontIconifyByUnmapping { win-list }</p>

okay so this one is the exception list bestie ๐Ÿ’… it names a list of windows that should not get iconified by simply unmapping the window โ€” which is exactly what would've happened if IconifyByUnmapping had been set. So you're basically going "bestie, not you, you're special."

This gets used all the time to force some windows to be treated as icons while the rest of them just get handled by the icon manager. iconic behavior tbh ๐ŸŽ€


DontInterpolateTitles</p>

this is a lil modification to how InterpolateMenuColors behaves โœจ and it does one very specific thing: it makes vtwm not apply color interpolation to any titles that sit in the middle of the menu.

So those f.title strings lurking in the middle of the menu (aka the ones that don't have a specific color defined for them) will just inherit the default MenuTitle foreground and background colors instead. no interpolation for the middle children, periodt. ๐Ÿฆ‹


DontMoveOff</p>

this variable says: windows are not allowed to be moved off the screen. no yeeting your windows into the void!! ๐Ÿ˜ญ

it can be overridden by the f.forcemove function, so if you really need to shove something off-screen, f.forcemove is your girl ๐Ÿ’…


DontShowInDisplay { list }</p>

a list of clients that should not show up in the desktop display ๐Ÿซถ

The default is:

DontShowInDisplay
{
    "VTWM *"
    "xclock"
    "xload"
}

DontShowInTwmWindows { list }</p>

DontShowInVtwmWindows { list }</p>

these two are the same vibe as the last one, but for the menu instead of the display: they specify a list of clients that should not appear in the VTWM Windows menu ๐Ÿ‘‘


DontSqueezeTitle [{ win-list }]</p>

this variable means titlebars should not be squeezed down to their minimum size โ€” the squeezing described down there under SqueezeTitle ๐Ÿ‘‡

and if you pass the optional window list, then only those windows get protected from being squeezed. picky, and honestly? valid. ๐Ÿ’…


DoorBackground color [{ door-list }]</p>

sets the background colors of doors ๐Ÿšชโœจ

The default is "maroon" for color displays, or "gray50" for monochrome displays.


DoorBevelWidth pixels</p>

tells vtwm to use 3D-looking doors, and says how wide the bevel is, in pixels ๐Ÿ’ซ

The default is 0 if vtwm is built with 2D features, or 1 when vtwm is built with 3D features.


DoorFont string</p>

the font used for text in doors ๐Ÿšช๐Ÿ“

โš ๏ธ this one must be set in order to see the doors. no font, no doors, bestie.

The default is "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*".


DoorForeground color [{ door-list }]</p>

sets the foreground colors of doors ๐Ÿšช๐ŸŒˆ

The default is "gray85".


Doors { door-list }</p>

THIS is the one that actually creates doors ๐Ÿšช and doors, bestie, are teleports. absolutely main character energy, no cap. โœจ

Each item in the door-list has this format:

"winname"    "location"    "jumpTo"

Windows named winname show up with the geometry and position defined in location, and they warp you to jumpTo when f.enterdoor gets executed inside them ๐ŸŒ€

Doors have a class of "VTWM Door".


EnhancedExecResources</p>

okay so by default, f.exec variables behaved the way they always did in vtwm โ€” meaning you had to append " &" to all of your variables just to run them without blocking the window manager. annoying fr fr ๐Ÿ˜ญ

With this option turned on you don't have to! vtwm will automatically append " &" to the f.exec variable โ€” unless the last non-space character is either '&', or ';' (in case you still want a command to block the window manager on purpose). ๐Ÿ‘‘

for example, in a variable like:

f.exec "foo; bar; baz"

the window manager will be blocked, so that "foo" and "bar" can be executed. "baz" is the only command which will NOT block the window manager.

if you want all of these commands to be backgrounded, try this:

f.exec "{ foo; bar; baz }" # note that "{" and "}"
                           # are shell keywords; they
                           # MUST be separated by
                           # spaces.

and if you still want a command to block the window manager, you'd use:

f.exec "xset fp rehash;" # vtwm will not append " &"
                         # because ';' is the last
                         # non-space character.

this behavior was inspired by that of vuewm(1), Hewlett-Packard's workspace implementation of mwm(1). shoutout to the ancestors ๐Ÿ™Œ


FixManagedVirtualGeometries</p>

FixTransientVirtualGeometries</p>

these two are bug workarounds that should fix the way most windows' virtual geometries are handled โ€” like, they should be on the real screen if the parent windows are on the real screen, no matter where the virtual desktop is (and xv(1) is one example of how these don't work, so likeโ€ฆ mostly. ๐Ÿ˜…)

They are both set by default.


ForceIcons</p>

this variable says the icon image files specified in the Icons variable should override any client-supplied images ๐Ÿ’ช sorry client, my icons win.


FramePadding pixels</p>

this one sets the distance between the titlebar font, or the titlebar button height (whichever is greater), and the window frame โ€” enlarging the titlebar as needed ๐Ÿ“

See also ButtonIndent for how it influences the titlebar ๐Ÿ‘€

The default is 2 pixels.


IconBackground string [{ win-list }]</p>

sets the background color of icons ๐ŸŽจ and it may only be specified inside of a Color or Monochrome list, okay?? important detail.

the optional win-list is a list of window names and colors so you can do per-window colors ๐Ÿ’– See the BorderColor variable for a complete description of the win-list.

The default is "maroon" for color displays, or "gray50" for monochrome displays.


IconBevelWidth pixels</p>

tells vtwm to use 3D-looking icons, and specifies the width of the bevel in pixels โœจ

The default is 0 if vtwm is built with 2D features, or 2 when vtwm is built with 3D features.


IconBorderColor string [{ win-list }]</p>

the color of the border used for icon windows ๐Ÿ–ผ๏ธ and again, it may only be specified inside of a Color or Monochrome list.

the optional win-list is a list of window names and colors for per-window colors ๐Ÿ’œ See the BorderColor variable for the full description of the win-list.

The default is "gray85".


IconBorderWidth pixels</p>

sets the width, in pixels, of the border surrounding icon windows ๐ŸŽ€

The default is 2 if vtwm is built with 2D features, or 0 when vtwm is built with 3D features.


IconDirectory string</p>

this one names the directory that should be searched if an image file can't be found in any of the directories in the bitmapFilePath variable ๐Ÿ” it's the backup bestie, the emergency contact, the "hey do you have it at home" directory. ๐Ÿ 


IconFont string</p>

the font used to display icon names inside of icons ๐Ÿ”ค

The default is "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*".


IconForeground string [{ win-list }]</p>

the foreground color used when displaying icons ๐ŸŒˆ and yep โ€” it may only be specified inside of a Color or Monochrome list.

the optional win-list is a list of window names and colors so per-window colors are possible ๐Ÿ’… See the BorderColor variable for the complete description of the win-list.

The default is "gray85".


IconifyByUnmapping [{ win-list }]</p>

this variable says windows should be iconified by getting unmapped without trying to map any icons ๐Ÿซฅ it's giving "poof, gone."

If the optional win-list is provided, then only those windows get iconified by simply unmapping.

โš ๏ธ windows that have both this and the IconManagerDontShow options set may not be accessible โ€” unless the user has provided bindings to the warp functions (f.warp and the like) while WarpUnmapped is set, or by the VTWM Windows menu. so likeโ€ฆ careful, bestie ๐Ÿ’€

It is set by default.


IconManagerBackground string [{ win-list }]</p>

the background color to use for icon manager entries ๐ŸŽจ may only be specified inside of a Color or Monochrome list.

the optional win-list is a list of window names and colors for per-window colors โœจ See the BorderColor variable for the complete description of the win-list.

The default is "maroon" for color displays, or "gray50" for monochrome displays.


IconManagerBevelWidth pixels</p>

tells vtwm to use 3D-looking icon manager entries, and specifies the width of their bevels in pixels ๐ŸŒŸ

The default is 0 if vtwm is built with 2D features, or 1 when vtwm is built with 3D features.


IconManagerDontShow [{ win-list }]</p>

says the icon manager should not display any windows ๐Ÿ™ˆ if the optional win-list is given, then only those windows won't be displayed.

this is the variable you use to stop windows that are rarely iconified (like xclock or xload) from taking up precious real estate in the icon manager ๐Ÿ‘‘

The default is:

IconManagerDontShow
{
    "VTWM *"
    "xclock"
    "xload"
}

IconManagerFont string</p>

the font used when displaying icon manager entries ๐Ÿ”ค

The default is "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*".


IconManagerForeground string [{ win-list }]</p>

the foreground color used when displaying icon manager entries ๐ŸŒˆ may only be specified inside of a Color or Monochrome list.

the optional win-list is a list of window names and colors so per-window colors are on the table ๐Ÿ’… See the BorderColor variable for a complete description of the win-list.

The default is "gray85".


IconManagerGeometry string [ columns ]</p>

this one says: hey, create a default icon manager, with the geometry specified by string ๐Ÿ“

The string argument should be a standard X geometry specification, specifying the initial size and/or location.

The icon manager window then gets broken into columns pieces and scaled according to the number of entries in the icon manager โœจ extra entries get wrapped around to form additional rows.

The default string is "+0+0", and the default columns is 1.


๐Ÿ’… IconManagerHighlight string [{ win-list }]

This one sets the border color for when the icon manager entry that's got the focus gets highlighted, bestie. Heads up tho: it can only go inside a Color or Monochrome list. The optional win-list is a list of window names + colors so you can do per-window colors, see BorderColor for the full deets on how win-list works. Default is "black". ๐Ÿ–ค

โœจ IconManagers { iconmgr-list }

Okay so this one lets you build a whole list of icon managers to create on top of the default one (y'know, the one you get if IconManagerGeometry is used). Each item in the iconmgr-list looks like:

"winname"    ["iconname"]    "geometry"    columns

Where winname = the name of the windows that should land in this icon manager, iconname = the name of that icon manager window's icon, geometry = a standard geometry spec, and columns = how many columns this icon manager has, just like in IconManagerGeometry. For example:

IconManagers
{
    "XTerm"     "300x5+800+5"    5
    "myhost"    "400x5+100+5"    2
}

So clients whose name or class is "XTerm" get an entry made in the "XTerm" icon manager, and clients named "myhost" get yeeted into the "myhost" icon manager. ๐Ÿ‘‘

๐ŸŽ€ IconManagerShow { win-list }

A list of windows that should show up in the icon manager. Team it up with IconManagerDontShow and only the windows on this list will be shown. By default, literally every window is shown except the ones in IconManagerDontShow.

๐Ÿฆ‹ IconRegion geomstr vgrav hgrav hgrid vgrid

This specifies an area on the root window where icons go when the client didn't give a specific icon location. geomstr is a quoted string with a standard geometry spec for the region's size and location. If you give more than one IconRegion line, icons spill into the next regions once the first is full. vgrav is either North or South and decides whether icons fill in from the top or the bottom of the region. Same energy for hgrav, which is either East or West and decides if icons fill in from the left or the right. Icons get laid out in a grid with cells hgrid pixels wide and vgrid pixels high.

โš ๏ธ The smallest dimension of the region has to be at least the size of the largest icon in it, in that same direction. Also, so many apps change their icon name while running, and there's no provision made to reformat the icon regions if an icon changes size because of that. Watch out. ๐Ÿ˜ญ

๐ŸŒˆ Icons { win-list }

A list of window names plus the image filenames to use as their icons. Like:

Icons
{
    "XTerm"    "xterm.icon"
    "xfd"      "xfd_icon"
}

Windows matching "XTerm" that wouldn't be iconified by unmapping will try to use the icon image from the file "xterm.icon". And if ForceIcons is set, that image gets used even if the client asked for its own icon image. stubborn behavior, we love it ๐Ÿ’…

๐Ÿ’€ IgnoreModifiers modlist

Specifies the "shift states" to ignore when vtwm is figuring out if an event is bound. Like in this example:

IgnoreModifiers    l | m2

the CapsLock and NumLock states get ignored.

โš ๏ธ ngl, using this variable can generate a lot of X protocol network traffic, so keep modlist as small as you possibly can. See also the BINDINGS section.

๐Ÿ“ InfoBevelWidth pixels

Tells vtwm to use 3D-looking identify, move and resize windows, and sets the bevel width in pixels. Default is 0 if vtwm is built with 2D features, or 2 when it's built with 3D features.

๐Ÿงš InfoFont string

The font used in the identify window. Default is "-adobe-helvetica-bold-r-normal--*-100-*-*-*-*-*-*".

๐Ÿ’œ InterpolateMenuColors

Says menu entry colors should be interpolated between the colors you specified for entries. In this example:

Menu    "mymenu"
{
    "Title"     ("black":"red")      f.title
    "entry1"                         f.nop
    "entry2"                         f.nop
    "entry3"    ("white":"green")    f.nop
    "entry4"                         f.nop
    "entry5"    ("red":"white")      f.nop
}

the foreground colors for "entry1" and "entry2" get interpolated between black and white, and the background colors between red and green. Same vibe for "entry4": its foreground lands half-way between white and red, and the background half-way between green and white. math ate, fr fr ๐ŸŒˆ

โญ LessRandomZoomZoom

Turn this on and random zooms get a lil less "random" and a lil more visible. Might make a better visual bell, depends on your personal taste, bestie.

๐Ÿซถ MakeTitle { win-list }

A list of windows that should get a titlebar. This is how you request titles on specific windows when NoTitle has been set. give them their crown ๐Ÿ‘‘

๐Ÿ”ฅ MaxWindowSize string

A geometry where the width and height give the max size for a given window. Usually used to keep windows within the size of the screen. Default is "30000x30000".

The background color used for menus, and it can only go inside a Color or Monochrome list. Default is "maroon" for color displays or "gray50" for monochrome displays.

Tells vtwm to use 3D-looking menus, and sets the bevel width in pixels. Default is 0 if vtwm is built with 2D features, or 2 if built with 3D features.

The font used when displaying menus. Default is "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*".

The foreground color used for menus, can only go inside a Color or Monochrome list. Default is "gray85".

When a menu's contents would make it taller than the display, moving the pointer within pixels of the top or bottom of the menu makes it scroll its entries. Default is 2.

How many entries to scroll when the pointer moves into the area defined by MenuScrollBorderWidth. Default is 3 entries.

The color of the shadow behind pull-down menus, can only go inside a Color or Monochrome list. Default is "black".

The background color for f.title entries in menus, can only go inside a Color or Monochrome list. Default is "gray70".

The font used in menu titles. Default is "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*".

The foreground color for f.title entries in menus, can only go inside a Color or Monochrome list. Default is "maroon" for color displays or "gray50" for monochrome displays.

โญ Monochrome { colors }

A list of color assignments to make if the screen has a depth of 1. See the description of Colors.

๐Ÿซถ MoveDelta pixels

How many pixels the pointer has to move before the f.move and f.resize functions and initial menu highlighting start working. See also the f.deltastop function. Default is 3 pixels.

๐Ÿ”ฅ NailedAbove

Makes nailed windows sit physically above non-nailed windows. The f.nailedabove function can toggle this setting.

๐ŸŒธ NailedDown { list }

A list of clients that start out nailed. The default is:

NailedDown
{
    "VTWM *"
    "xclock"
    "xload"
}

โœจ NaturalAutopanBehavior

By default, when autopanning, the pointer is warped by only

(AutoPanBorderWidth + AutoPanExtraWarp)

pixels on the real screen. Turn this one on and the pointer gets warped on the real screen by as many pixels as the screen is scrolled, or the above value, whichever is greater. So the pointer normally doesn't move very much (only by AutoPanExtraWarp) relative to the virtual desktop.

This works really well on faster X terminals and workstations, but for slower ones you might wanna use the following:

AutoPanWarpWithRespectToRealScreen    50

to achieve a similar effect. Setting NaturalAutopanBehavior has the exact same effect as using the variable

AutoPanWarpWithRespectToRealScreen    100

๐ŸŽ€ NoBackingStore

Says vtwm's windows should not request backing store, so it minimizes repainting. Typically used with servers that can repaint faster than they can handle backing store. speedy queens only โšก

๐Ÿฆ‹ NoBorder [{ win-list }]

Windows shouldn't have borders. If you give the optional win-list, only those windows skip the borders. no border, no problem ๐Ÿ’…

๐ŸŒˆ NoBorderDecorations

Says the 3D borders of titled windows should not have those little divots adorning the corners.

  • NoCaseSensitive โ€” okay so this one tells vtwm to ignore case when it's sorting icon names in an icon manager. Bestie, you want this when your apps are out here capitalizing the first letter of their icon name and the sort order starts looking all kinds of cursed. ๐Ÿ’…
  • NoDefaultMouseOrKeyboardBindings โ€” says vtwm should not supply the default pointer and keyboard bindings. โš ๏ธ Only use this if your startup file contains a completely new set of pointer and keyboard bindings and definitions โ€” like, a full replacement, no leftovers. See also NoDefaults.
  • NoDefaults โ€” vtwm should not supply the default titlebar buttons and bindings. Again, only reach for this if the startup file has a completely new set of bindings and definitions, because otherwise you're just sitting there with a window and no way to grab it. It's giving chaos. This one has the effect of setting both NoDefaultMouseOrKeyboardBindings and NoDefaultTitleButtons. ๐Ÿ‘‘
  • NoDefaultTitleButtons โ€” vtwm should not supply the default titlebar buttons. Periodt. Only if the startup file contains a completely new set of titlebar button definitions. See also NoDefaults.
  • NoGrabServer โ€” tells vtwm to minimize server grabs when it's popping up menus and moving or resizing windows. Less grabbing, smoother vibes. โœจ
  • NoHighlight [{ win-list }] โ€” borders should not be highlighted to track the location of the pointer. If you pass the optional win-list, highlighting only gets switched off for those windows. When a border is highlighted, it's drawn in the current BorderColor. When it's not highlighted, it gets stippled with a gray pattern using the current BorderTileForeground and BorderTileBackground colors. It is set by default if vtwm is built with 3D features. ๐Ÿฆ‹
  • NoIconManagerFocus โ€” vtwm should not set focus to windows corresponding to their entries in an icon manager. Normally vtwm sets the focus so that events from an icon manager are delivered to the application. Typically this is set to facilitate icon manager bindings that would otherwise be delivered to the application. iykyk ๐Ÿ’œ
  • NoIconManagerHighlight โ€” icon manager entries will not be highlighted to track the location of the pointer. This is independent of the NoHighlight variable.
  • NoIconManagers โ€” no icon manager should be created. Like, none. Zero. Not a single one. ๐Ÿšซ๐ŸŒธ
  • NoIconifyIconManagers โ€” no icon manager should be iconified.
  • NoMenuShadows โ€” menus should not have drop shadows drawn behind them. Typically used with slower servers, since it speeds up menu drawing at the expense of making the menu slightly harder to read. The eternal tradeoff, bestie. ๐Ÿ˜ญ
  • NoOpaqueMove [{ win-list }], NoOpaqueResize [{ win-list }] โ€” these two say the f.move and f.resize functions should change just a window's outline. If the optional win-list is given, only those windows are affected. These are usually used to narrow the scope of "global" OpaqueMove and OpaqueResize variables.
  • NoPrettyTitles โ€” for when you literally don't mind long titles butting up against the right edge of short titlebars and icon managers. ๐Ÿ’€ It disables the default behavior of using ellipses to indicate a truncated title.
  • NoRaiseOnDeiconify, NoRaiseOnMove, NoRaiseOnResize, NoRaiseOnWarp โ€” these say windows should not be raised after a deiconify, move, resize, or warp operation, and they're typically used to preserve the window stacking order. โš ๏ธ Real talk though: the pointer may end up in an occluding window when these variables are used.
  • NoSaveUnders โ€” menus should not request save-unders, which minimizes window repainting following a menu selection. Typically used with displays that can repaint faster than they can handle save-unders.
  • NoStackMode [{ win-list }] โ€” client window requests to change the stacking order should be ignored. If the optional win-list is given, only requests on those windows get ignored. Typically used to prevent applications from relentlessly popping themselves to the front of the window stack. Main character syndrome apps, we see you. ๐Ÿ‘€
  • NoTitle [{ win-list }] โ€” windows should not have titlebars. If the optional win-list is given, only those windows go titlebar-free. MakeTitle may be used along with this option to force titlebars onto specific windows. The default is:
NoTitle
{
    "VTWM *"
    "xclock"
    "xload"
}
  • NoTitleFocus โ€” vtwm should not set keyboard input focus to each window as it is entered. Normally vtwm sets the focus so that focus and key events from the titlebar and icon managers are delivered to the application. But if the pointer is moved quickly and vtwm is slow to respond, input can get directed to the old window instead of the new one. ๐Ÿ˜ญ This option is typically used to prevent this "input lag" and to work around bugs in older applications that have problems with focus events.
  • NoTitleHighlight [{ win-list }] โ€” the highlight area of the titlebar, the bit that indicates which window currently has the input focus, should not be displayed. If the optional win-list is given, only those windows go without highlight areas. This one plus the SqueezeTitle options can be set to substantially reduce the amount of screen space required by titlebars. Space-saving icon behavior. ๐ŸŽ€
  • NotVirtualGeometries โ€” vtwm should assume that user geometries are relative to the current virtual window, as opposed to absolute. If you set this, then xterm -geometry +20+20 specifies a position in the current view; otherwise, it would specify a position in the top-left view. It is set by default.
  • NoWindowRing { win-list } โ€” specifies a list of windows that will not be added to the list along which the f.warpring function cycles. See also WindowRing.
  • OldFashionedTwmWindowsMenu, OldFashionedVtwmWindowsMenu โ€” by default, the VTWM Windows menu uses the same colors you see in the panner. This variable disables that behavior. Retro vibes only. ๐ŸŒˆ
  • OpaqueMove [{ win-list }], OpaqueResize [{ win-list }] โ€” these say the f.move and f.resize functions should actually change the window instead of just an outline, so you can immediately see what the window will look like. If the optional win-list is given, only those windows get affected "opaquely". Typically used on fast systems (particularly when NoGrabServer is set). ๐Ÿ”ฅ
  • PanDistanceX N, PanDistanceY N โ€” these define a grid of screens for the virtual desktop, expressed as N% of a real screen. When the f.snap function is called, the real screen gets moved to the closest grid location. The (mis)naming of these variables is for historical reasons. The default value is 100, which effectively sets up "pages" in the virtual desktop.
  • PanResistance milliseconds โ€” how hard it should be to pan to an adjacent virtual screen. It specifies how long the pointer must be within AutoPanBorderWidth pixels of the real screen's edge. Values equal to 0 or greater than 10000 disable this feature. Default is 750 milliseconds.
  • PauseOnExit N, PauseOnQuit N โ€” these define a delay on exit, expressed in seconds. They let the (vtwm stop) and f.quit sounds have time to play before the connection to rplayd(8) is closed. ๐ŸŽต
  • Pixmaps { pixmaps } โ€” specifies a list of images that define the appearance of various windows. Each entry is a keyword indicating the window to set, followed by a string giving the name of the image. Built-in and external images may be freely mixed, given the constraints described in the IMAGE AND AUDIO FORMATS section. The following windows may be specified thus:
Pixmaps
{
    TitleHighlight             ":xpm:sunkenbox"
    RealScreenPixmap           "scaledbackground.xpm"
    VirtualBackgroundPixmap    "gray1"
    MenuIconPixmap             ":xpm:rarrow"
    IconManagerPixmap          ":xpm:zoom"
}

By default, the TitleHighlight is an even, stippled pattern if vtwm is built with 2D features, or "sunken" lines when vtwm is built with 3D features. The MenuIconPixmap is a right arrow by default (rendered 3D as appropriate), and the default IconManagerPixmap is either the X logo or a "raised" box, for 2D or 3D features, respectively. Customize away. โœจ

  • PointerPlacement โ€” windows with no specified geometry should be placed with the window origin at the location of the mouse pointer or, if WarpSnug is specified, as close as possible to that location such that the window fits onto the real screen. If RandomPlacement is also set then it takes precedence.
  • PrettyZoom โ€” if Zoom is turned on, this makes the associated animation look just a little nicer, depending on your personal taste. It makes the zoom slower, however, so you may have to decrease the value of the Zoom variable. Beautiful but slow is a whole mood. ๐Ÿ˜ญ
  • RaiseDelay milliseconds โ€” for windows that are to be automatically raised when the pointer enters (see the AutoRaise variable and the f.autoraise function), this variable specifies the length of time the pointer should rest in the window before it is raised. The default is 0 milliseconds.

RaiseOnStart ๐Ÿ‘‘

ok so normally the raise happens at the end of a move or resize (and yeah, that's subject to MoveDelta, NoRaiseOnMove, and NoRaiseOnResize). This variable says "no bestie, raise at the start instead." Honestly kinda slay when you've got OpaqueMove and/or OpaqueResize turned on.

โš ๏ธ but fr fr watch out: if you cancel a move or resize while this is set, the window stacking order will not be preserved. no undo on that one, sorry ๐Ÿ’€

RandomPlacement ๐ŸŽฒ

Windows that show up with no geometry specified get dropped in a pseudo-random spot instead of making you drag an outline around โ€” or the window itself, if OpaqueMove is set โ€” to wherever you want it. Surprise placement, it's giving chaos but make it convenient โœจ

RealScreenBackground string

see RealScreenForeground below, babe ๐Ÿ’–

RealScreenBorderWidth pixels

Sets the border width of the RealScreen window (again, RealScreenForeground has the lore). Default is 0 pixels. so, like, no border unless you ask.

RealScreenForeground string

okay this one needs a little story time ๐ŸŒธ inside what vtwm calls the virtual desktop window โ€” but which we can just call the "panner" โ€” there's a lil window showing where your physical screen sits in virtual space. The vtwm source code calls this lil window the RealScreen.

By default it has no border, so the only way you can tell it apart from the normal panner backdrop is its color or its image. And heads up: its foreground color has no meaning unless you give it an image. (You can give it a border โ€” that's what RealScreenBorderWidth is for. ๐ŸŽ€)

RealScreenPixmap string

Names an image file to decorate the RealScreen window with ๐Ÿ–ผ๏ธ A sample ships with it, nestedsqu.xbm, but ngl your mileage may vary as the size of your screen varies! The move is to just find out the size of this window and make yourself any image file of type bitmap(1) or pixmap(1) for it โ€” that's the recommended procedure, periodt.

ResizeFont string

Sets the font for that little dimensions window that pops up while you're resizing ๐Ÿฆ‹ Default is "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*" โ€” copy it exactly, no typos bestie.

ResizeRegion location

Tells vtwm where on the screen to show that resize window. location has to be one of: NorthWest, NorthEast, SouthWest, SouthEast, or Centered. Pick your vibe ๐Ÿ“

RestartPreviousState โœจ

This one says vtwm should try to read the WM_STATE property on client windows to figure out which windows should be iconified and which should stay visible. Classic use case: regenerating the state your screen was in before the previous window manager got shut down. It is set by default. she comes pre-loaded ๐Ÿ’…

RightHandSidePulldownMenus ๐Ÿซฑ

So pull-down menus can show up when your pointer is to the right of the center of their parent menu, or they can show up when your pointer is closer to the right edge of their parent menu. This option turns on the latter behavior, and yeah โ€” it's the default. ๐Ÿ˜Œ

SaveColor { colors-list } ๐ŸŒˆ

A list of color assignments to stash as pixel values in the root window property _MIT_PRIORITY_COLORS. Clients can elect to preserve these values when they install their own colormap. Why care? Because using this mechanism is a way for an application to avoid the "technicolor" problem โ€” that cursed situation where useful screen objects like window borders and titlebars just disappear when a program's custom colors get installed by the window manager. ๐Ÿ˜ญ

For example:

SaveColor
{
    BorderColor
    TitleBackground
    TitleForeground
    "red"
    "green"
    "blue"
}

That would place on the root window 3 pixel values for borders and titlebars, plus the three color strings, all taken from the default colormap. cute, right?

ShallowReliefWindowButton ๐Ÿ“

Makes the built-in 3D titlebar buttons, the 3D icon manager button, the 3D menu pull-right icon, and the 3D titlebar highlight area render with a "flatter" look. It is set by default if vtwm is built with 3D features. soft launch relief, we love her.

ShowIconManager ๐Ÿ‘‘

Says the icon manager window should be visible right when vtwm starts. And no stress if you change your mind โ€” you can always bring it up with the f.showiconmgr function. โœจ

SnapRealScreen ๐Ÿ“

Makes the real screen snap to a grid defined in PanDistanceX and PanDistanceY increments, every time the representation moves. Wanna toggle it? The f.snaprealscreen function does exactly that. ๐Ÿ”ฅ

SortIconManager ๐Ÿ”ค

Icon manager entries get sorted alphabetically instead of just tacking new windows onto the end. It is set by default โ€” organized queen behavior ๐Ÿ’…

SoundHost string

Specifies which machine โ€” by its TCP/IP hostname โ€” is running the rplayd(8) daemon. If you don't specify anything, the local machine gets tried. And if rplayd(8) can't be accessed at all? Sound gets toggled off. bye bestie ๐Ÿ‘‹

Sounds { sound-list } ๐Ÿ”Š

A list of identifiers paired with sound files. Each entry looks like this:

"identifier"    "soundfile"    [volume]

where identifier is any function described in the BINDINGS section โ€” except f.playsound, f.sounds, and f.separator โ€” plus these event identifiers: (vtwm start), (vtwm stop), (client map), (client unmap), (menu map), (menu unmap), (info unmap), (autopan event), and (bell event).

The soundfile is the full pathname of the sound file to play for that identifier, and volume sets the volume to play it at (see also SoundVolume).

โš ๏ธ note that the list entries must be quoted! don't skip the quotes, it will not go well ๐Ÿ˜ญ

For example:

Sounds
{
    "(vtwm start)"    "/usr/share/sounds/wowee.wav"
    "(vtwm stop)"     "/usr/share/sounds/seeya.wav"
    "f.exec"          "/usr/share/sounds/click.au"   50
    "(client map)"    "/usr/share/sounds/ping.au"    50
    "f.delete"        "/usr/share/sounds/doh1.wav"
    "f.deletedoor"    "/usr/share/sounds/doh2.wav"
    "f.destroy"       "/usr/share/sounds/doh3.wav"
    "(client unmap)"  "/usr/share/sounds/ping.au"
}

This example points out that some identifiers "overlap":

f.beep > (bell event)            f.exec > (client map)
f.delete > (client unmap)        f.menu > (menu map)
f.deletedoor > (client unmap)    f.quit > (vtwm stop)
f.destroy > (client unmap)       f.version = f.identify

In these cases, the function takes precedence over the event when both would otherwise play. so the function wins the vibe check, every time ๐Ÿ†

SoundVolume N ๐Ÿ”‰

Sets the overall volume sounds play at, expressed as N% of maximum. Default is 25 (that's 1/4 attenuation). not too loud, not too quiet โ€” main character volume โœจ

SqueezeTitle [{ squeeze-list }] ๐ŸŽ€

Tells vtwm to use the SHAPE extension to make titlebars take up only as much screen space as they actually need, instead of stretching all the way across the top of the window. Obsessed with a titlebar that knows its boundaries ๐Ÿ’…

The optional squeeze-list controls where the squeezed titlebar sits along the top of the window. Each entry looks like:

"name"    justification    num    denom

where name is a window name, justification is either left, center, or right, and num and denom are numbers specifying a ratio for the relative position about which the titlebar is located, measured from left to right.

ok let's decode that ratio lore ๐Ÿ“–

  • A ratio of 0/0 means the justification is absolute.
  • A non-zero numerator with a zero denominator means a pixel count.
  • For any other ratio, the justification is ignored entirely.

For example:

SqueezeTitle
{
    "XTerm"     left      0    0
    "xterm1"    left      1    3
    "xterm2"    right     2    3
    "oclock"    center    0    0
    "emacs"     right     0    0
}

And if you wanna turn squeezing off for certain titles, the DontSqueezeTitle list is right there for you. It is set by default. โœ…

StartIconified [{ win-list }] ๐ŸŒ™

Says client windows should start out left as icons until the user explicitly deiconifies them. If you pass the optional win-list, then only those windows start iconic. Super useful for programs that don't support an -iconic command line option or resource โ€” we do a lil workaround, no biggie โœจ

StaticIconPositions ๐Ÿ“Œ

Changes up icon placement so that icons keep their positions on the virtual desktop when they're not nailed and DeiconifyToScreen isn't being used. This is most applicable when SnapRealScreen and AutoPan are used with PanDistanceX and PanDistanceY values to simulate ctwm(1) workspaces. big fan of a stable grid, icl ๐Ÿ”ฅ

StayUpMenus ๐Ÿซถ

This one changes how menu interaction works. Normally, a menu item gets selected when you release a pointer button over it. This variable makes menu items get selected on the next button press event instead. click-first energy ๐Ÿ’…

StayUpOptionalMenus ๐Ÿ˜Œ

Similar to StayUpMenus, except โ€” plot twist โ€” if any menu items are selected, the menu interaction reverts to the old behavior. Let's look at an example: suppose you've got the right pointer button bound to bring up a menu with a title bar.

  • Clicking the right button and releasing it (over the title bar) brings up the menu and has it stay up until you click on a menu item.
  • Clicking the right button, moving the pointer to a menu item, and releasing the right button activates that menu item and dismisses the menu.

both vibes, one setting ๐ŸŒธ

Sticky { list } ๐Ÿฏ

A synonym for NailedDown. that's it, that's the whole thing ๐Ÿ’–

StickyAbove โœจ

A synonym for NailedAbove. also it ๐Ÿ’…

StrictIconManager ๐Ÿง

Makes icon managers list only those windows that are in an iconified state. no clutter, no extras, just the icons. we respect a strict queen ๐Ÿ‘‘

  • TitleBackground string [{ win-list }] โ€” this is the background color of your titlebars, bestie. Important caveat tho</p>: you can only set it inside a Color or Monochrome list. That optional win-list? It's a list of window names + colors so you can do per-window titlebar colors, because why be consistent when you could be extra. Default is "maroon" on color displays or "gray50" on monochrome ones. ๐Ÿ’…
  • TitleBevelWidth pixels โ€” tells vtwm you want 3D-looking titlebars, and sets the width in pixels of the bevel wrapping around the titlebar. Little detail: if ButtonIndent plus FramePadding equals zero, then the bevel gets bound to the text and highlight area instead. Default is 0 when vtwm is built with 2D features, or 1 when it's built with 3D features. โœจ
  • TitleButtonBorderWidth pixels โ€” the width in pixels of the border around titlebar buttons, and it's drawn in the TitleForeground color. Default is 1 when vtwm is built with 2D bitmaps, or 0 when it's built with 3D pixmaps.
  • TitleFont string โ€” the font used to display window names in the titlebars. Default is "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*". Yes that's a whole lot of dashes, no I will not be explaining the XLFD, it's giving โœจ 1990s arcana โœจ.
  • TitleForeground string [{ win-list }] โ€” the foreground color of your titlebars. Same rule as the background one, queen: it may only be specified inside of a Color or Monochrome list. The optional win-list is a list of window names and colors so per-window colors may be specified. Default is "maroon" for color displays or "gray50" for monochrome displays.
  • TitlePadding pixels โ€” the distance between titlebar buttons in the titlebar. Heads up on the fine print: the distances between buttons and the title, the title and the highlight area, and the highlight area and the buttons are all set to a hard-coded value, so don't go looking for six more variables to tune them, they don't exist. Default is 5 if vtwm is built with 2D features, or 0 when it's built with 3D features.
  • UnknownIcon string โ€” the filename of an image file to be used as the default icon. This image becomes the icon of every client that doesn't provide its own icon image and isn't listed in the Icons list. It's giving pity icon, but make it cute. ๐ŸŽ€
  • UsePPosition string [{ win-list }] โ€” do we honor program-requested locations (the ones from the PPosition flag in the WM_NORMAL_HINTS property) when the user hasn't asked for a specific position? The argument string has three possible values:
    • "off" โ€” the default, meaning vtwm just ignores the program-supplied position ๐Ÿ™ˆ
    • "on" โ€” use the position, respect the program's wishes
    • "non-zero" โ€” use the position, but only if it's something other than (0,0); this one exists to work around a bug in older toolkits

And the optional win-list is a list of window names and arguments that override the global string argument. Real example, straight from the source:

    UsePPosition    "off"
    {
        "MPlayer"   "on"
    }
  • VirtualBackground string โ€” the background color for the panner, a.k.a. the Virtual Desktop window. Default is "maroon" for color displays or "gray50" for monochrome displays.
  • VirtualBackgroundPixmap string โ€” names an image file to decorate the panner. Pimp your panner, bestie. ๐Ÿฆ‹
  • VirtualForeground string โ€” foreground for the panner. Genuinely has no use unless you specify a panner image of type bitmap(1), so don't be surprised when it does nothing.
  • VirtualDesktop geometry scale โ€” this one is the whole point. You must set this variable to enable the virtual desktop features of vtwm. If you don't set it, vtwm behaves exactly the same way as twm. This variable says where to place the virtual desktop window and how big it is. The geometry is a standard X geometry specification and it defines the size and location of the window containing the desktop representation.

The scale parameter specifies the scaling of the virtual desktop window compared to the desktop. The size specification can be given in three ways:

  • If size is larger than the screen size, it represents the size of the whole desktop, and the virtual window desktop size will then be size divided by scale.
  • When size times scale is smaller than the screen size, size represents the number of screens that should fit in the desktop.
  • Otherwise size represents the size of the virtual desktop window, and the currently accessible virtual desktop is then scale times the size of the desktop window.

Using the default as an example:

    VirtualDesktop    "5x2-0-0"    16

With scale set to 16, and a physical screen size of 1024x768, the desktop area is 1/16 the size of the screen times the number of screens specified:

    (5 * (1024 / 16)) x (2 * (768 / 16)) = 320 x 96

And the glow-up: the size of the desktop can be changed dynamically, by simply resizing the virtual desktop window. ๐Ÿ”ฅ

  • VirtualDesktopBevelWidth pixels โ€” tells vtwm to use a 3D-looking virtual desktop, and specifies the width in pixels of the bevel. Default is 0 if vtwm is built with 2D features, or 1 when vtwm is built with 3D features.
  • VirtualDesktopFont font โ€” causes font to be used when displaying the names of windows in the virtual desktop display. If you don't set this variable, the names just won't be displayed at all, fr fr. And for the feature to actually be useful you should also set DesktopDisplayForeground. Default is "-adobe-helvetica-medium-r-normal--*-75-*-*-*-*-*-*".
  • VirtualReceivesMotionEvents
  • VirtualSendsMotionEvents โ€” these two variables indicate that changes to the position and dimension of windows on the real screen will be reflected in the virtual desktop as they occur, and vice versa. Synced. Slay. ๐Ÿซถ
  • WarpCentered string โ€” by default, when warping to windows, the pointer goes to either the center of the titlebar, or if there isn't one, the center of the top border member. This variable says the pointer should instead warp to the center of the window, depending on the string argument:
    • "on" โ€” all windows
    • "titled" โ€” titled windows only
    • "untitled" โ€” untitled windows only
    • "off" โ€” the default, i.e. the default behavior described above

Note that warps to icon managers are exceptional (iykyk): the pointer always goes to either the active entry, or if there isn't one, the top entry. No override for that one.

  • WarpCursor [{ win-list }] โ€” says the pointer should be warped into windows when they're deiconified. If the optional win-list is given, the pointer only gets warped when those windows are deiconified โ€” very picky of you, love that. It is set by default.
  • WarpSnug โ€” with this set, the warp functions (f.warp and the like) will fit the entire window on the screen, i.e. they'll be snugged on the real screen. Cozy. ๐Ÿงš
  • WarpToTransients โ€” says the pointer should be warped into transient windows when they are created.
  • WarpUnmapped โ€” says the warp functions (f.warp and the like) should deiconify any iconified windows they encounter. Typically used to make a key binding that pops a particular window (such as xmh) no matter where it is. The default is for the functions to ignore iconified windows.
  • WarpVisible โ€” says the warp functions f.warpclassnext, f.warpclassprev, f.warpring, and f.warpto should restrict themselves to windows that are on the screen. The default is for the functions to traverse the entire virtual desktop, so set this if you want them staying local. ๐Ÿ‘‘
  • WarpWindows โ€” when warping to a window, by default the real screen gets moved to find that window on the virtual desktop. With this set, it flips: the window itself gets warped to the real screen, moving the window in the virtual desktop instead.
  • WindowRing [{ win-list }] โ€” says that when windows are created, they should be added to the list that the f.warpring function operates on. If the optional win-list is given, then only those windows get included in the window ring. See also NoWindowRing and f.ring. ๐ŸŽ€
  • XorValue number โ€” the value to use when drawing window outlines for moving and resizing. You should set it to a value that results in a variety of distinguishable colors when exclusive-or'ed with the contents of your typical screen. Setting it to 1 often gives nice results if adjacent colors in the default colormap are distinct. By default, vtwm will attempt to cause temporary lines to appear at the opposite end of the colormap from the graphics.
  • Zoom [ count ] โ€” says that outlines suggesting the movement of a window to and from its iconified state should be displayed whenever a window is iconified or deiconified. The optional count argument specifies how many outlines get drawn. The default count is 8.
  • ZoomZoom โ€” modifies zooms so a random place gets used for the source or destination when there isn't an appropriate window (e.g., an icon, icon manager entry, or client window). The default behavior inhibits zooms when there aren't appropriate windows, except for the f.zoomzoom function.

๐Ÿ’– SPECIAL VARIABLES ๐Ÿ’–

These following variables have to be set after the fonts have been assigned, so honestly it's usually best to put them at the end of the variables section or the beginning of the bindings sections. Order matters, bestie, no cap. โœจ

  • DefaultFunction function โ€” the function to execute when a key or button event comes in that has no binding provided for it. Typically you'd bind this to f.nop, f.beep, or a menu containing window operations. It's your catch-all, your no thoughts head empty handler. ๐Ÿ˜ญ
  • WindowFunction function โ€” the function to execute when a window is selected from the VTWM Windows menu. If this variable isn't set (that's the default), the window gets deiconified and raised. And heads up, with love: it is strongly recommended that if you do set this, the function includes provision for deiconifying windows. Otherwise you're gonna have a bad time. ๐Ÿ’€

โœจ BINDINGS โœจ

okay so once all your variables are set (slay), it's time to attach functions to stuff โ€” titlebar buttons, keys, pointer buttons, the whole vibe. ๐Ÿ’…

Titlebar buttons can be added from the left side or the right side, and they show up in the titlebar left-to-right in exactly the order you specify them. Key and pointer button bindings tho? Those can be given in any order, do whatever, no pressure. ๐Ÿฆ‹

Titlebutton specs have to include the name of the image to use in the button box and the function to invoke when a pointer button gets pressed inside them:

LeftTitleButton  "image" = function

or

RightTitleButton "image" = function

go check out the ButtonIndent and FramePadding variables plus the IMAGE AND AUDIO FORMATS section if you want the deets on how to specify the image. ๐Ÿ‘‘

Key and pointer button specs need three things: the modifiers that must be pressed, over which parts of the screen the pointer has to be, and what function to invoke. Keys are written as strings containing the appropriate keysym name; buttons are written as the keywords Button1-Button5:

"FP1"   = modlist : context : function
Button1 = modlist : context : function

The modlist is any combination of the modifier names shift, control, lock, meta, mod1, mod2, mod3, mod4, or mod5 โ€” which may be abbreviated as s, c, l, m, m1, m2, m3, m4, m5 respectively โ€” separated by a vertical bar (|). Same energy for the context: any combination of window, title, icon, root, frame, virtual, desktop, door, iconmgr, their first letters (careful, the iconmgr abbreviation is m, and door has no abbreviation), or all, all separated by a vertical bar. It is rumored that window class names also work. ๐Ÿ‘€ The function is any of the f. keywords described below.

fr fr, the default startup file contains these bindings:

Button1 =   : root          : f.menu "VTWM Windows"
Button1 = m : window | icon : f.function "move-or-lower"
Button2 = m : window | icon : f.iconify
Button3 = m : window | icon : f.move
Button1 =   : title         : f.move
Button2 =   : title         : f.raiselower
Button1 =   : icon          : f.function "move-or-iconify"
Button2 =   : icon          : f.iconify
Button1 =   : iconmgr       : f.iconify
Button2 =   : iconmgr       : f.iconify

And if you're the type of girlie who wants to manipulate windows straight from the keyboard ๐Ÿ’ปโœจ, you could roll with these:

"F1"    =       : all : f.iconify
"F2"    =       : all : f.raiselower
"F3"    =       : all : f.warpring "next"
"F4"    =       : all : f.warpto "xmh"
"F5"    =       : all : f.warpto "emacs"
"F6"    =       : all : f.colormap "next"
"F7"    =       : all : f.colormap "default"
"F20"   =       : all : f.warptoscreen "next"
"Left"  = m     : all : f.backiconmgr
"Right" = m | s : all : f.forwiconmgr
"Up"    = m     : all : f.upiconmgr
"Down"  = m | s : all : f.downiconmgr
โš ๏ธ okay but real talk โ€” using all for button or key bindings is almost always a bad idea, because it stops every single application from receiving those events. That can straight up cripple text and graphics editors that otherwise expect to see those buttons or keys. (see also the IgnoreModifiers variable, and the f.bindbuttons, f.bindkeys, f.unbindbuttons, and f.unbindkeys functions. iykyk)

vtwm serves up so many more window manipulation primitives than can conveniently fit in a titlebar, a menu, or a set of key bindings. Like, an embarrassing amount. ๐Ÿ™ˆ A small set of defaults are supplied (unless NoDefaults, NoDefaultMouseOrKeyboardBindings, or NoDefaultTitleButtons is specified), but most users are gonna wanna have their most common operations bound to key and button strokes. To do that, vtwm associates names with each of the primitives and gives you user-defined functions for building higher level primitives, plus menus for interactively picking between groups of functions. ๐Ÿ’–

User-defined functions contain the name by which they're referenced in calls to f.function and a list of other functions to execute. For example:

Function "move-or-lower"    { f.move f.deltastop f.lower }
Function "move-or-iconify"  { f.move f.deltastop f.iconify }
Function "restore-colormap" { f.colormap "default" f.lower }

The function name must be used in f.function exactly as it appears in the function specification. no typos bestie, it will not forgive you. ๐Ÿ˜ญ

๐Ÿ’– VTWM PROFILE ๐Ÿ’–

If a function called "VTWM Profile" is defined within the startup file, that function will be executed upon startup or restarting of the window manager. For example:

AutoPan    25
Function   "VTWM Profile"
{
    f.autopan
}

this gives AutoPan a value but turns autopanning off initially (it won't have a value unless AutoPan is set in the startup file; see f.autopan below), in case you wanna turn it on sometime later. ๐ŸŽ€


In the descriptions below, if the function is said to operate on the selected window, but is invoked from a root menu, the cursor will be changed to the Select cursor and the next window to receive a button press will be chosen:

  • ! string โ€” this is just an abbreviation for f.exec string. shorthand queen. โœจ
  • ^ string (OBSOLETE โ€” use a clipboard client) โ€” this is an abbreviation for f.cut string.
  • f.autopan โ€” if autopan wasn't configured in your .vtwmrc file, this does nothing. If it was configured tho, it toggles the current autopan state. The reason this command exists is that autopan is sometimes nice to have, but it interferes with using sticky windows that are near the edge of the screen. With this command, you get the best of both worlds. ๐Ÿ‘‘
  • f.autoraise โ€” toggles whether or not the selected window is raised whenever it's entered by the pointer. See the description of the variable AutoRaise.
  • f.backiconmgr โ€” warps the pointer to the previous column in the current icon manager, wrapping back to the previous row if necessary. ๐Ÿฆ‹
  • f.beep โ€” sounds the keyboard bell. that's it. that's the function. ๐Ÿ“ข
  • f.bindbuttons
  • f.bindkeys โ€” these functions enable vtwm's pointer or keyboard bindings for the selected window. They're only needed if the bindings have been disabled with the f.unbindbuttons or f.unbindkeys functions. โš ๏ธ Be careful what you bind these functions to; f.bindkeys bound to a window context key will not be accessable after f.unbindkeys is invoked for the window!
  • f.bottomzoom โ€” similar to the f.fullzoom function, but resizes the window to fill only the bottom half of the screen.
  • f.circledown โ€” lowers the top-most window that occludes another window.
  • f.circleup โ€” raises the bottom-most window that is occluded by another window.
  • f.colormap string โ€” rotates the colormaps (obtained from the WM_COLORMAP_WINDOWS property on the window) that vtwm will display when the pointer is in this window. The argument string may have one of the following values: "next", "prev", and "default".

Should be noted here that in general, the installed colormap is determined by keyboard focus. A pointer driven keyboard focus will install a private colormap upon entry of the window owning the colormap. Using the click to type model, private colormaps will not be installed until the user presses a pointer button on the target window.

  • f.cut string (OBSOLETE โ€” use a clipboard client) โ€” places the specified string (followed by a newline character) into the root window property CUT_BUFFER0.
  • f.cutfile (OBSOLETE โ€” use a clipboard client) โ€” reads the file indicated by the contents of the CUT_BUFFER0 window property and replaces the cut buffer.
  • f.deiconify โ€” deiconifies the selected window. If the window is not an icon, this function does nothing. ๐Ÿซถ
  • f.delete โ€” sends the WM_DELETE_WINDOW message to the selected window if the client application has requested it through the WM_PROTOCOLS window property. The application is supposed to respond to the message by removing the window. If the window has not requested WM_DELETE_WINDOW messages, the keyboard bell will be rung indicating that the user should choose an alternative method. ๐Ÿ“ข

Note this is very different from f.destroy. The intent here is to delete a single window, not necessarily the entire application.

  • f.deletedoor โ€” deletes a door.
  • f.deltastop โ€” allows a user-defined function to be aborted if the pointer has been moved more than MoveDelta pixels. See the example definition given for Function "move-or-lower" at the beginning of the section.
  • f.destroy โ€” instructs the X server to close the display connection of the client that created the selected window. This should only be used as a last resort for shutting down runaway clients. See also f.delete.
๐Ÿ’€ This action sometimes leaves a runaway process that consumes CPU cycles; you should always try to use the applications own quit function, rather than this one. seriously bestie, try the app's quit first.
  • f.downiconmgr โ€” warps the pointer to the next row in the current icon manger, wrapping to the beginning of the next column if necessary. (yes it says "manger" in the source, we don't ask questions, we just vibe ๐Ÿงš)
  • f.enterdoor โ€” activates this door. Typically one binds:
Button1 = : door : f.enterdoor
Button2 = : door : f.enterdoor
Button3 = : door : f.enterdoor
  • f.exec string โ€” passes the argument string to /bin/sh for execution. In multiscreen mode, if string starts a new X client without giving a display argument, the client will appear on the screen from which this function was invoked. โœจ
  • f.file string (OBSOLETE โ€” use a clipboard client) โ€” assumes string is a file name. This file is read into the window server's cut buffer.
  • f.focus โ€” toggles the keyboard focus of the server to the selected window, changing the focus rule from pointer-driven if necessary. If the selected window already was focused, this function executes an f.unfocus. ๐Ÿ’…
  • f.forcemove โ€” like f.move except that it ignores the DontMoveOff variable. rules? never heard of her.
  • f.forwiconmgr โ€” warps the pointer to the next column in the current icon manager, wrapping to the beginning of the next row if necessary. ๐Ÿฆ‹
  • f.fullzoom โ€” resizes the selected window to the full size of the display ๐Ÿ–ฅ๏ธ โ€ฆor, if it was already zoomed, restores the original size instead. Toggle queen behavior. โœจ
  • f.function string โ€” runs the user-defined function whose name is given by the argument string.
  • f.hbzoom โ€” synonym for f.bottomzoom. Same energy, different name ๐Ÿ’…
  • f.hidedesktopdisplay โ€” unmaps the desktop display. Poof, gone ๐Ÿ™ˆ
  • f.hideiconmgr โ€” unmaps the current icon manager when you fire it from a client window, and unmaps all icon managers when you fire it from the root window.
  • f.horizoom โ€” basically f.zoom, except the selected window gets resized to the full width of the display. (The man page calls this a "variable" โ€” bestie, it's a function, we're not fighting about it ๐Ÿ’€)
  • f.htzoom โ€” synonym for f.topzoom.
  • f.hzoom โ€” synonym for f.horizoom.
  • f.iconify โ€” iconifies or deiconifies the selected window or icon, respectively. Little window, big window, your call ๐ŸŽ€
  • f.identify โ€” shows a summary of the name and geometry of the selected window. Click the pointer or press a key inside that window to dismiss it. And if you invoke it on a desktop representation of a window, it identifies the real window being represented. โœจ
  • f.lefticonmgr โ€” same as f.backiconmgr, except wrapping does not change rows.
  • f.leftzoom โ€” similar to the f.bottomzoom function, but the selected window only gets resized to the left half of the display.
  • f.lower โ€” lowers the selected window. Down you go, bestie ๐Ÿฆ‹
  • f.menu string โ€” invokes the menu specified by the argument string. You can build cascaded menus by nesting calls to f.menu โ€” menus inside menus inside menus, it's giving inception ๐Ÿ˜ญ
  • f.move โ€” drags an outline of the selected window (or the window itself if the OpaqueMove variable is set) until you release the invoking pointer button, and at that point the window is raised (subject to RaiseOnStart, MoveDelta, and NoRaiseOnMove). Double clicking within the number of milliseconds given by ConstrainedMoveTime warps the pointer to the center of the window and constrains the move horizontally or vertically, depending on pointer movement. To abort the move, press another button before releasing the invoking button. ๐Ÿซถ
  • f.movescreen โ€” moves a window (or possibly the real screen) inside the desktop display. To abort the move, press another button before releasing the invoking button. By default, the bindings using the desktop context are defined as:
    Button1 = : desktop : f.movescreen
    Button2 = : desktop : f.movescreen

This is useful if you want to reset the default keyboard and pointer bindings via NoDefaultMouseOrKeyboardBindings and use some of your own for the virtual desktop, e.g.:

    NoDefaultMouseOrKeyboardBindings
    Button1 = : desktop : f.movescreen
    Button2 = : desktop : f.warp
    Button3 = : desktop : f.iconify
Under any context other than "desktop", this function is not useful.
  • f.nail โ€” nails or unnails the selected window onto the real screen; the current value of this property is toggled on the window. ๐Ÿ“Œ
  • f.nailedabove โ€” toggles the setting of the NailedAbove variable.
  • f.namedoor โ€” bound to the door context, this one pastes a name from CUT_BUFFER0 into the selected door (peep the BINDINGS section for the deets).
  • f.newdoor โ€” creates a new door with it's destination and name set to the real screen's current position in the virtual desktop. ๐Ÿšชโœจ
  • f.nexticonmgr โ€” warps the pointer to the next icon manager containing any windows on the current or any succeeding screens.
  • f.nop โ€” does absolutely nothing ๐Ÿซ  and is typically used with the DefaultFunction or WindowFunction variables, or to introduce blank lines in menus.
  • f.panup N, f.pandown N, f.panleft N, f.panright N โ€” these move the real screen by N% of the screen dimension in the indicated direction. They're ideally bound to the cursor keys:
    "Up"    = : root : f.panup    "100"
    "Down"  = : root : f.pandown  "100"
    "Left"  = : root : f.panleft  "100"
    "Right" = : root : f.panright "100"
  • f.playsound soundfile โ€” plays the specified sound at SoundVolume volume. The soundfile must be the full pathname of the sound file. Heads up though: this is a rather "expensive" function compared to the one provided by the Sounds variable, and should be avoided. ๐Ÿ’ธ
  • f.previconmgr โ€” warps the pointer to the previous icon manager containing any windows on the current or preceding screens.
  • f.quit โ€” causes vtwm to restore the window's borders and exit. If vtwm is the last client invoked from xdm, this will result in a server reset, and the user's session will be logged out. ๐Ÿ˜ญ

Users who stay logged in for long periods (days or weeks), or who like to change window managers, or experiment with them, may find it desirable to use a relatively simple application, such as xbiff(1), as the last application in their .xinitrc or .xsession file, letting the window manager start earlier, and run in the background. This allows changing window managers without logging out, and also makes it much less likely that a session will be abruptly terminated by a bug in a complex program like a window manager. The one drawback to this approach is that f.quit then no longer terminates the session: you need to use f.delete or f.destroy on that last application to logout.

  • f.raise โ€” raises the selected window. โฌ†๏ธ
  • f.raiselower โ€” raises the selected window to the top of the stacking order if it's occluded by any windows; otherwise the window will be lowered.
  • f.refresh โ€” causes all windows to be refreshed. Glow-up for your whole desktop ๐ŸŒˆ
  • f.resetdesktop โ€” moves the real display to (0,0).
  • f.resize โ€” drags an outline of the selected window (or the window itself if the OpaqueResize variable is set) after crossing a border (or by setting AutoRelativeResize) until you release the invoking pointer button, at which time the window is raised (subject to RaiseOnStart, MoveDelta, and NoRaiseOnResize). To abort the resize, press another button before releasing the invoking button. โœ‹
  • f.restart โ€” kills and restarts vtwm. See also f.startwm.
  • f.righticonmgr โ€” similar to f.nexticonmgr, except wrapping does not change rows.
  • f.rightzoom โ€” similar to the f.bottomzoom function, except the selected window is only resized to the right half of the display.
  • f.ring โ€” selects a window and adds it to the WindowRing list, or removes it if it was already in the ring. This command makes f.warpring much more useful, by making its configuration dynamic. ๐Ÿ’
  • f.saveyourself โ€” sends a WM_SAVEYOURSELF message to the selected window if it has requested the message in its WM_PROTOCOLS window property. Clients that accept this message are supposed to checkpoint all state associated with the window and update the WM_COMMAND property as specified in the ICCCM. If the window has not requested this message, the keyboard bell will be rung. ๐Ÿ””
  • f.separator โ€” valid only in menus. The effect is to add a line separator between the previous and the following entry. The name selector part in the menu is not used (but must be present). ๐ŸŽ€
  • f.setrealscreen geomstr โ€” sets the real screen to the virtual coordinates specified. The geomstr is a quoted string containing a standard geometry specification.
  • f.showdesktopdisplay โ€” maps the desktop display.
  • f.showiconmgr โ€” maps the current icon manager when selected from a client window, and maps all icon managers when selected from the root window.
  • f.snap โ€” snaps the real screen to a grid defined on virtual space with PanDistanceX and PanDistanceY increments. ๐Ÿ“
  • f.snaprealscreen โ€” toggles the setting of SnapRealScreen.
  • f.snugdesktop โ€” moves the display to try to fit all partially visible windows completely on the screen.
  • f.snugwindow โ€” moves the display to try to fit the selected window completely on the screen.
  • f.sorticonmgr โ€” sorts the entries in the current icon manager alphabetically. See the variable SortIconManager.
  • f.sounds โ€” toggles the playing of sounds. It's a "mute" function. ๐Ÿ”‡
  • f.squeezecenter, f.squeezeleft, f.squeezeright โ€” selects a window and makes its title appear as though you had configured it as
    SqueezeTitle    center    0    0

or

    SqueezeTitle    left      0    0

or

    SqueezeTitle    right     0    0

respectively. These make squeezed titles much more useful because their configuration is dynamic. โœจ

  • f.startwm commandline โ€” kills vtwm, and starts up the window manager as specified by commandline. A trailing ampersand and/or environment variables should not be used. See also f.restart.
  • f.staticiconpositions โ€” toggles the setting of StaticIconPositions.
  • f.stick โ€” synonym for f.nail.
  • f.stickyabove โ€” synonymous with the f.nailedabove function.
  • f.stricticonmgr โ€” toggles the setting of StrictIconManager.
  • f.title โ€” provides a centered, unselectable item in a menu definition. It should not be used in any other context. ๐Ÿ‘‘
  • f.topzoom โ€” similar to the f.bottomzoom function, except the selected window is only resized to the top half of the display.
  • f.twmrc โ€” literally the same thing as f.restart bestie, they're twins ๐Ÿ’… back in the day tho it was supposed to make vtwm re-read your startup customization file, that was the whole og plan.
  • f.unbindbuttons
  • f.unbindkeys โ€” these two switch OFF vtwm's pointer and keyboard bindings for whichever window you picked, so events just slide straight through to the app itself ๐Ÿซถ super handy when you're running another window manager inside Xnest or Xvnc, iykyk.
  • f.unfocus โ€” puts the focus back on pointer-driven mode โœจ use this when you're done with a focused window and you don't want it anymore.
  • f.upiconmgr โ€” warps the pointer up to the previous row in the icon manager you're in rn, and if it hits the top it wraps around to the last row of that same column. queen of never getting stuck ๐Ÿ‘‘
  • f.version โ€” pops up the vtwm version window ๐ŸŽ€ it stays up until you press a pointer button or move the pointer from one window to another.
  • f.virtualgeometries โ€” flips the setting of NotVirtualGeometries on and off, toggling vibes only.
  • f.vlzoom โ€” it's giving f.leftzoom. synonym, same energy ๐Ÿ’–
  • f.vrzoom โ€” and this one is a synonym for f.rightzoom ๐ŸŒธ
  • f.warp โ€” yanks the cursor over to the window you selected. ngl it's only actually useful if you selected that window through the icon manager ๐Ÿ™ˆ
  • f.warpclassnext string
  • f.warpclassprev string โ€” these two warp the pointer to the next or previous window in the class you name in the string argument ๐Ÿฆ‹ if string is "VTWM", then only icon managers, doors, and the Virtual Desktop window get considered. if string is empty (so like, ""), it uses the class of the window that currently has focus. and if that window is iconified? it gets deiconified if the WarpUnmapped variable is set, otherwise it just gets flat-out ignored ๐Ÿ’€
  • f.warpring string โ€” warps the pointer to the next or previous window in the WindowRing variable โ€” which one you get depends on string, and it can be "next" or "prev" โญ if the window is iconified, it gets deiconified when WarpUnmapped is set, otherwise ignored, same rules as above fr fr.
  • f.warpsnug โ€” toggles WarpSnug on and off ๐ŸŒˆ
  • f.warpto string โ€” warps the pointer to the window whose name or class matches string. string can be a VTWM-style wildcard, but not a regular expression, ok? (go check the WILDCARDS section for the deets) ๐Ÿ”ฅ and yeah โ€” iconified window gets deiconified if WarpUnmapped is set, otherwise it's getting ignored.
  • f.warptoiconmgr string โ€” warps the pointer to the icon manager entry attached to the window that's got the pointer, inside the icon manager you name in string. if string is empty (like, ""), the current icon manager is the one that gets picked ๐Ÿ’œ and if the window's iconified, deiconified if WarpUnmapped is set, else ignored. same rules, every time, no cap.
  • f.warptonewest โ€” warps the pointer to the most recently created window ๐Ÿ‘‘ and yes โ€” iconified window gets deiconified if WarpUnmapped is set, else ignored.
  • f.warptoscreen string โ€” warps the pointer to the screen named by string. string can be a number (like "0" or "1"), or the word "next" (which means the current screen plus 1, hopping right over any unmanaged screens), or the word "back" (current screen minus 1, also hopping over unmanaged screens), or the word "prev" (which means the last screen visited).
  • f.warpvisible โ€” toggles WarpVisible โœจ
  • f.winrefresh โ€” basically f.refresh's cousin, except only the selected window gets refreshed ๐ŸŽ€
  • f.zoom โ€” like f.fullzoom but make it lowkey โ€” only the height of the selected window changes ๐Ÿ’…
  • f.zoomzoom โ€” draws a zoom outline from one random spot to another random spot (see the Zoom and ZoomZoom variables). it's silly, bestie, it's not that deep ๐Ÿ˜ญ but you can use it as a visual bell instead of f.beep. also peep the LessRandomZoomZoom variable.

okay so you can group functions together and pick them interactively with menus โ€” pop-up menus (when you bind them to a pointer button) or pull-down menus (when you hook them onto a titlebar button) โœจ every menu spec has: the menu's name, as f.menu will call it; optional default foreground and background colors; the list of item names and the functions they fire; and optional foreground and background colors for each individual item:

Menu    "menuname"    [ ("deffore":"defback") ]
{
    string1    [ ("fore1":"back1")]    function1
    string2    [ ("fore2":"back2")]    function2
      ...
    stringN    [ ("foreN":"backN")]    functionN
}

The menuname is case-sensitive, don't play with it ๐Ÿ™ˆ. The optional deffore and defback arguments are the foreground and background colors used on a color display to highlight menu entries. The string part of each menu entry is the text that shows up in the menu. The optional fore and back arguments set the foreground and background colors of that menu entry when the pointer isn't in it. those colors only do anything on a color display ๐Ÿ’… and by default it just uses whatever colors the MenuForeground and MenuBackground variables say. the function part of a menu entry is one of the functions โ€” user-defined ones count too โ€” or another menu entirely. menu-ception, it's giving iconic ๐Ÿงš

There's a special menu named VTWM Windows and it contains the names of all the client windows and the vtwm-supplied windows ๐Ÿ”ฅ pick an entry and it runs the WindowFunction on that window. if WindowFunction hasn't been set, the window just gets deiconified and raised. this menu uses the same colors as the little windows in the panner, cute right? and bestie โ€” this feature still honors the traditional TwmWindows menu name of yore, because we respect our elders ๐Ÿซถ


๐Ÿฆ‹ ICONS ๐Ÿฆ‹

vtwm lets you mess with iconified windows in a few different ways ๐Ÿ’– the classic image-and-text style can be laid out by hand or auto-arranged, which is what the IconRegion variable is for. plus there's a terse little grid of icon names called an icon manager โ€” it uses screen space way more efficiently and lets you navigate between windows from the keyboard, main character energy fr fr.

An icon manager is a window holding the names of selected windows, or all of them, that are currently on the display โœจ besides the window name, a small button using the default iconify symbol shows up to the left of the name whenever the window is iconified. by default, clicking an entry in the icon manager performs f.iconify. wanna change what happens in the icon manager? use the iconmgr context when you're setting up your button and keyboard bindings ๐ŸŒธ

Moving the pointer into the icon manager also hands keyboard focus to the indicated window โ€” as long as NoIconManagerFocus isn't set (it sets the focus explicitly, or else sends synthetic events if NoTitleFocus is set). And with the f.upiconmgr, f.downiconmgr, f.lefticonmgr, and f.righticonmgr functions, you can flip the input focus between windows straight from the keyboard ๐Ÿ‘‘


๐ŸŒˆ IMAGE AND AUDIO FORMATS ๐ŸŒˆ

vtwm can handle a whole bunch of images all on its own (this doc calls those "internal" or "built-in"), split into two types: bitmaps and pixmaps ๐ŸŽ€ you can tell them apart from file images because they start with either a colon (':') or the string ":xpm:" as their first character(s), respectively:

:darrow             scaled in any, n/a for highlight
:delete / :xlogo    centered in any drawable
:dot / :iconify     centered in any drawable
:menu               scaled in any drawable
:rarrow             scaled in any, n/a for highlight
:resize             scaled in any drawable

:xpm:bar            scaled in any drawable
:xpm:box            scaled in any drawable
:xpm:darrow         scaled in any, n/a for highlight
:xpm:dot            centered in any drawable
:xpm:lines          scaled in any drawable
:xpm:menu           scaled in any drawable
:xpm:raisedbox      scaled, for highlight only
:xpm:raisedlines    scaled, for highlight only
:xpm:rarrow         scaled in any, n/a for highlight
:xpm:resize         scaled in any drawable
:xpm:sunkenbox      scaled, for highlight only
:xpm:sunkenlines    scaled, for highlight only
:xpm:zoom           scaled in any drawable

vtwm also supports exactly one image file format by default โ€” the X Window System bitmap (files that usually carry a ".xbm" extension) for two-color images โญ BUT, when it's built with the XPM library, vtwm also handles the X Window System pixmap (files that usually carry a ".xpm" extension) for full-color images ๐Ÿ”ฅ full color, full drama.

All image types and sources can be freely mixed within the variables that use them, given the behavior listed above, plus these extra exceptions, no cap:

  • The Icons and UnknownIcon variables don't recognize the built-in images ๐Ÿ™ˆ
  • The RealScreenPixmap, TitleHighlight, and VirtualBackgroundPixmap entries of the Pixmaps variable don't recognize the built-in images either
  • Only titlebar buttons can accommodate external images that would be bigger than the default space allocated for them (in any other case, the image just gets cropped to fit โœ‚๏ธ)
  • And only the RealScreenPixmap, TitleHighlight, and VirtualBackgroundPixmap entries of the Pixmaps variable will tile small images into the space allocated for them ๐Ÿงฉ

Sizing tea โ˜• the icon manager drawable is hard-coded to 11x11 pixels, the menu drawable is MenuFont pixels square, and titlebar buttons are (TitleFont - (2 * ButtonIndent)) pixels square. The titlebar highlight area is (titlebar height - (2 * FramePadding) - 2) pixels high โ€” where titlebar height is determined by TitleFont or the titlebar button height, whichever one is greater, and FramePadding ๐Ÿ’… math is math, bestie.

Your root window can be decorated with whatever image files the X Window System utilities and applications support โ€” think xloadimage(1), xsetroot(1), xv(1), etc. โœจ aesthetic: achieved.

And if vtwm is built with sound support, there are several audio file formats supported โ€” not by vtwm itself tho, by the rplayd(8) daemon ๐ŸŽง rn the AU, AIFF, WAV, and VOC formats are natively supported, but also go peep rplay.helpers(5) for more.

๐ŸŒˆ WILDCARDS

okay bestie so vtwm does "wildcarding" when it's matching windows against a variable's win-list. ๐Ÿ’– By default:

  • ? โ€” any single character
  • * โ€” any zero or more characters
  • [ and ] โ€” any characters listed inside them
  • \ โ€” "escapes" any one character, so you can use those reserved cuties literally ๐Ÿ’…

vtwm can also support a way richer method of character substitution called regular expressions, aka "RE"s โœจ. If vtwm is built with REs, so many more "wildcard" rules get added. Describing REs is beyond the scope of this doc though โ€” go peek at the re_format(7) or egrep(1) man pages, iykyk.

vtwm tells REs apart from strings by wrapping them in forward slashes (/). And the two can be freely mixed, no drama ๐Ÿซถ. So if you take the example from the VARIABLES section and change it to:

AutoRaise
{
    "emacs"
    "VTWM*"
    /x.*clock/    # was "x*clock"
    "Xmh"
    "XTerm"
}

it does literally the same thing. But ngl this is just a lil baby example of RE usage, so it doesn't really flex or show off what REs can do. ๐Ÿ™ˆ


โšก ASYNCHRONOUS EVENTS

You can issue an f.restart via a Unix signal โ€” which is lowkey such a vibe for debugging your vtwm resource files. ๐ŸŽ€ To do it, send a SIGUSR1 to the vtwm process ID (which gets written to $HOME/vtwm.pid). Go see kill(1) or slay(1). ๐Ÿ’€


๐Ÿ’€ BUGS

There are precious few safeguards against binding functions to objects inappropriately, especially where the virtual desktop is concerned. ๐Ÿ˜ญ

Double clicking very fast to get the constrained move function will sometimes cause the window to move, even though the pointer is not moved.

It is possible to 'lose' windows in the virtual desktop by placing them in a large desktop area, then shrinking the desktop so as to remove them from view. They are still there, of course, but are unreachable until the

See the BUGS file in the distribution for others. ๐Ÿ‘‘

๐Ÿ“ FILES

  • $HOME/.vtwmrc.screen-number
  • $HOME/.vtwmrc
  • $VTWMETCMDIR/vtwm/system.vtwmrc
  • $HOME/.twmrc.screen-number
  • $HOME/.twmrc
  • $VTWMETCMDIR/twm/system.vtwmrc

these are the files vtwm will search for and use as its config file ๐Ÿงš. They get searched in the order shown above, and the first readable one found is the one it uses. periodt.

  • $HOME/vtwm.pid โ€” holds the ID of your vtwm process; see the description of the -p option above. ๐Ÿ’–

๐ŸŒธ ENVIRONMENT

  • DISPLAY โ€” this variable decides which X server to use. It's also set during f.exec so that programs come up on the proper screen. โœจ
  • HOME โ€” used as the prefix for files that start with a tilde, and for locating the vtwm startup file. ๐Ÿ 

๐Ÿ‘‘ AUTHORS AND CONTRIBUTORS

Tom LaStrange, Solbourne Computer; Jim Fulton, MIT X Consortium; Steve Pitschke, Stardent Computer; Keith Packard, MIT X Consortium; Dave Payne, Apple Computer; Nick Williams <njw@athena.mit.edu>; Dave Edmondson, Santa Cruz Operation, <davided@sco.com>; Dana Chee, Bellcore (R5 conversion), <dana@thumper.bellcore.com>; Warren Jessop, University of Washington, <whj@cs.washington.edu>; Gilligan <thoth@reef.cis.ufl.edu>; Tim Ramsey <tar@math.ksu.edu>; Ralph Betza <gnohmon@ssiny.com>; Michael Kutzner <futzi@uni-paderborn.de>; Stig Ostholm <ostholm@ce.chalmers.se>; M. Eyckmans <mce@ping.be>; Tony Brannigan <tbrann@ox.ac.uk>; Alec Wolman <wolman@crl.dec.com>; <gdmr@dcs.edinburgh.ac.uk>; Marcel Mol <marcel@duteca.et.tudelft.nl>; Darren S. Embry <dsembr01@starbase.spd.louisville.edu>; Chris P. Ross <cross@eng.umd.edu>; Paul Falstad <pf@z-code.z-code.com>; D. J. Hawkey Jr., (version 5.4), <hawkeyd@visi.com>, with Erik Agsjo <erik.agsjo@aktiedirekt.com>, Ugen Antsilevitch <ugen@xonix.com>, Nelson H. F. Beebe <beebe@math.utah.edu>, Michael Dales <michael@dcs.gla.ac.uk>, Jennifer Elaan <jen@elaan.com>, Michel Eyckmans <mce@ping.be>, Callum Gibson <callum.gibson@db.com>, Jason Gloudon <jdg@world.std.com>, Nicholas Jacobs <nicholas_jacobs@hotmail.com>, Caveh Frank Jalali <caveh@eng.sun.com> Takeharu Kato <magician@maekawa.is.uec.ac.jp>, Goran Larsson <hoh@lorelei.approve.se>, Rolf Neugebauer <neugebar@dcs.gla.ac.uk>, Jonathan Paisley <jp@dcs.gla.ac.uk>, Steve Ratcliffe <sterat@dial.pipex.com>, Seth Robertson <seth@baka.org>, Mehul N. Sanghvi <mehul@kirsun.ne.mediaone.net>, Tim Wiess <tim@zetaflops.net>, acknowledging Claude Lecommandeur, (ctwm), <lecom@sic.epfl.ch>. ๐Ÿ’œ such a stacked roster fr fr


Copyright 1988 Evans & Sutherland Computer Corporation Copyright 1989 Massachusetts Institute of Technology Copyright 1990 Dave Edmondson Copyright 1990 Imperial College of Science, Technology & Medicine Copyright 1990, 1991 Groupe Bull Copyright 2001 David J. Hawkey Jr.

See the copyright notices in the vtwm source distribution for copyright license statements. On Debian systems, these may also be found in the file /usr/share/doc/vtwm/copyright. ๐Ÿ“œ


๐Ÿฆ‹ SEE ALSO

bitmap(1), ctwm(1), m4(1), mwm(1), pixmap(1), regex(7) or egrep(1), rplayd(8), tvtwm(1), twm(1), vuewm(1), X(1), xdm(1), xinit(1), xmodmap(1), xrdb(1), Xserver(1)


and that's the whole page bestie, we ate that UP ๐Ÿ”ฅ this was VTWM 5.4.7, dated 2005-06-28, and you officially know vtwm(1) now. go forth and manage some windows, main character ๐Ÿ’…โœจ๐ŸŽ€

๐Ÿ“ฆ where this page comes from