Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 1147 Details for
Bug 2951
fvwm.2.4.7.ebuild (Update)
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
patch against fvwm 2.4.7 for prettier titlebars
fvwm-pixmap-titlebar.patch (text/plain), 249.72 KB, created by
Tristan Henderson
on 2002-05-26 02:31:08 UTC
(
hide
)
Description:
patch against fvwm 2.4.7 for prettier titlebars
Filename:
MIME Type:
Creator:
Tristan Henderson
Created:
2002-05-26 02:31:08 UTC
Size:
249.72 KB
patch
obsolete
>diff -urN fvwm-2.4.7.orig/config.h.in fvwm-2.4.7/config.h.in >--- fvwm-2.4.7.orig/config.h.in Thu Apr 11 13:21:36 2002 >+++ fvwm-2.4.7/config.h.in Wed May 15 08:59:38 2002 >@@ -2,6 +2,9 @@ > /* Suffix for config filenames */ > #define FVWMRC ".fvwm2rc" > >+/* Define for fancy, multi-pixmap-themeable titlebars */ >+#define FANCY_TITLEBARS >+ > /* Define if gdk-imlib is used */ > #undef GDK_IMLIB > >diff -urN fvwm-2.4.7.orig/fvwm/borders.c fvwm-2.4.7/fvwm/borders.c >--- fvwm-2.4.7.orig/fvwm/borders.c Thu Dec 13 16:36:12 2001 >+++ fvwm-2.4.7/fvwm/borders.c Wed May 15 08:59:28 2002 >@@ -271,10 +271,29 @@ > case MiniIconButton: > case PixmapButton: > case TiledPixmapButton: >+#ifdef FANCY_TITLEBARS >+ case MultiPixmap: /* in case of UseTitleStyle */ >+#endif > if (type == PixmapButton || type == TiledPixmapButton) > { > p = df->u.p; > } >+#ifdef FANCY_TITLEBARS >+ else if (type == MultiPixmap) { >+ if (left1right0 && df->u.multi_pixmaps[TBP_LEFT_BUTTONS]) >+ p = df->u.multi_pixmaps[TBP_LEFT_BUTTONS]; >+ else if (!left1right0 && df->u.multi_pixmaps[TBP_RIGHT_BUTTONS]) >+ p = df->u.multi_pixmaps[TBP_RIGHT_BUTTONS]; >+ else if (df->u.multi_pixmaps[TBP_BUTTONS]) >+ p = df->u.multi_pixmaps[TBP_BUTTONS]; >+ else if (left1right0 && df->u.multi_pixmaps[TBP_LEFT_MAIN]) >+ p = df->u.multi_pixmaps[TBP_LEFT_MAIN]; >+ else if (!left1right0 && df->u.multi_pixmaps[TBP_RIGHT_MAIN]) >+ p = df->u.multi_pixmaps[TBP_RIGHT_MAIN]; >+ else >+ p = df->u.multi_pixmaps[TBP_MAIN]; >+ } >+#endif > else > { > if (!t->mini_icon) >@@ -298,6 +317,9 @@ > if (is_lowest && !p->mask && pbutton_background_pixmap) > { > if (type == TiledPixmapButton || >+#ifdef FANCY_TITLEBARS >+ type == MultiPixmap || >+#endif > (p && p->width >= width && p->height >= height)) > { > /* better performance: set a background pixmap if possible, i.e. if the >@@ -326,7 +348,11 @@ > XClearWindow(dpy, win); > } > } >- if (type != TiledPixmapButton) >+ if (type != TiledPixmapButton >+#ifdef FANCY_TITLEBARS >+ && type != MultiPixmap >+#endif >+ ) > { > if (DFS_H_JUSTIFICATION(df->style) == JUST_RIGHT) > x += (int)(width - p->width); >@@ -354,7 +380,11 @@ > > XSetClipMask(dpy, Scr.TransMaskGC, p->mask); > XSetClipOrigin(dpy, Scr.TransMaskGC, x, y); >- if (type != TiledPixmapButton) >+ if (type != TiledPixmapButton >+#ifdef FANCY_TITLEBARS >+ && type != MultiPixmap >+#endif >+ ) > { > int cx = x; > int cy = y; >@@ -448,6 +478,159 @@ > return; > } > >+#ifdef FANCY_TITLEBARS >+ >+/**************************************************************************** >+ * >+ * Tile or stretch src into dest, starting at the given location and >+ * continuing for the given width and height. This is a utility function used >+ * by DrawMultiPixmapTitlebar. (tril@igs.net) >+ * >+ ****************************************************************************/ >+static void RenderIntoWindow(GC gc, Picture *src, Window dest, int x_start, >+ int y_start, int width, int height, Bool stretch) >+{ >+ Pixmap pm; >+ if (stretch) >+ pm = CreateStretchPixmap(dpy, src->picture, src->width, src->height, >+ src->depth, width, height, gc); >+ else >+ pm = CreateTiledPixmap(dpy, src->picture, src->width, src->height, >+ width, height, src->depth, gc); >+ XCopyArea(dpy, pm, dest, gc, 0, 0, width, height, x_start, y_start); >+ XFreePixmap(dpy, pm); >+} >+ >+/**************************************************************************** >+ * >+ * Redraws multi-pixmap titlebar (tril@igs.net) >+ * >+ ****************************************************************************/ >+static void DrawMultiPixmapTitlebar(FvwmWindow *window, DecorFace *df) >+{ >+ Window title_win; >+ GC gc; >+ const char *title; >+ Picture **pm; >+ short stretch_flags; >+ int title_width, title_height, text_width, text_offset, text_y_pos; >+ int left_space, right_space, under_offset, under_width; >+ >+ pm = df->u.multi_pixmaps; >+ stretch_flags = df->u.multi_stretch_flags; >+ gc = Scr.TitleGC; >+ XSetClipMask(dpy, gc, None); >+ title_win = window->title_w; >+ title = window->name; >+ title_width = window->title_g.width; >+ title_height = window->title_g.height; >+ >+ if (pm[TBP_MAIN]) >+ RenderIntoWindow(gc, pm[TBP_MAIN], title_win, 0, 0, title_width, >+ title_height, (stretch_flags & (1 << TBP_MAIN))); >+ else if (!title) >+ RenderIntoWindow(gc, pm[TBP_LEFT_MAIN], title_win, 0, 0, title_width, >+ title_height, (stretch_flags & (1 << TBP_LEFT_MAIN))); >+ >+ if (title) { >+#ifdef I18N_MB >+ text_width = XmbTextEscapement(window->title_font.fontset, title, >+ strlen(title)); >+#else >+ text_width = XTextWidth(window->title_font.font, title, strlen(title)); >+#endif >+ if (text_width > title_width) >+ text_width = title_width; >+ switch (TB_JUSTIFICATION(GetDecor(window, titlebar))) { >+ case JUST_LEFT: >+ text_offset = TITLE_PADDING; >+ if (pm[TBP_LEFT_OF_TEXT]) >+ text_offset += pm[TBP_LEFT_OF_TEXT]->width; >+ if (pm[TBP_LEFT_END]) >+ text_offset += pm[TBP_LEFT_END]->width; >+ if (text_offset > title_width - text_width) >+ text_offset = title_width - text_width; >+ break; >+ case JUST_RIGHT: >+ text_offset = title_width - text_width - TITLE_PADDING; >+ if (pm[TBP_RIGHT_OF_TEXT]) >+ text_offset -= pm[TBP_RIGHT_OF_TEXT]->width; >+ if (pm[TBP_RIGHT_END]) >+ text_offset -= pm[TBP_RIGHT_END]->width; >+ if (text_offset < 0) >+ text_offset = 0; >+ break; >+ default: >+ text_offset = (title_width - text_width) / 2; >+ break; >+ } >+ under_offset = text_offset; >+ under_width = text_width; >+ /* If there's title padding, put it *inside* the undertext area: */ >+ if (under_offset >= TITLE_PADDING) { >+ under_offset -= TITLE_PADDING; >+ under_width += TITLE_PADDING; >+ } >+ if (under_offset + under_width + TITLE_PADDING <= title_width) >+ under_width += TITLE_PADDING; >+ left_space = under_offset; >+ right_space = title_width - left_space - under_width; >+ >+ if (pm[TBP_LEFT_MAIN] && left_space > 0) >+ RenderIntoWindow(gc, pm[TBP_LEFT_MAIN], title_win, 0, 0, left_space, >+ title_height, (stretch_flags & (1 << TBP_LEFT_MAIN))); >+ if (pm[TBP_RIGHT_MAIN] && right_space > 0) >+ RenderIntoWindow(gc, pm[TBP_RIGHT_MAIN], title_win, >+ under_offset + under_width, 0, right_space, >+ title_height, (stretch_flags & (1 << TBP_RIGHT_MAIN))); >+ if (pm[TBP_UNDER_TEXT] && under_width > 0) >+ RenderIntoWindow(gc, pm[TBP_UNDER_TEXT], title_win, under_offset, 0, >+ under_width, title_height, >+ (stretch_flags & (1 << TBP_UNDER_TEXT))); >+ if (pm[TBP_LEFT_OF_TEXT] && >+ pm[TBP_LEFT_OF_TEXT]->width <= left_space) { >+ XCopyArea(dpy, pm[TBP_LEFT_OF_TEXT]->picture, title_win, gc, 0, 0, >+ pm[TBP_LEFT_OF_TEXT]->width, title_height, >+ under_offset - pm[TBP_LEFT_OF_TEXT]->width, 0); >+ left_space -= pm[TBP_LEFT_OF_TEXT]->width; >+ } >+ if (pm[TBP_RIGHT_OF_TEXT] && >+ pm[TBP_RIGHT_OF_TEXT]->width <= right_space) { >+ XCopyArea(dpy, pm[TBP_RIGHT_OF_TEXT]->picture, title_win, gc, 0, 0, >+ pm[TBP_RIGHT_OF_TEXT]->width, title_height, >+ under_offset + under_width, 0); >+ right_space -= pm[TBP_RIGHT_OF_TEXT]->width; >+ } >+ >+ text_y_pos = title_height >+ - (title_height - window->title_font.font->ascent) / 2 >+ - 1; >+ if (title_height > 19) >+ text_y_pos--; >+ if (text_y_pos < 0) >+ text_y_pos = 0; >+#ifdef I18N_MB >+ XmbDrawString(dpy, title_win, window->title_font.fontset, gc, text_offset, >+ gc, text_offset, text_y_pos, title, strlen(title)); >+#else >+ XDrawString(dpy, title_win, gc, text_offset, text_y_pos, title, >+ strlen(title)); >+#endif >+ } >+ else >+ left_space = right_space = title_width; >+ >+ if (pm[TBP_LEFT_END] && pm[TBP_LEFT_END]->width <= left_space) >+ XCopyArea(dpy, pm[TBP_LEFT_END]->picture, title_win, gc, 0, 0, >+ pm[TBP_LEFT_END]->width, title_height, 0, 0); >+ if (pm[TBP_RIGHT_END] && pm[TBP_RIGHT_END]->width <= right_space) >+ XCopyArea(dpy, pm[TBP_RIGHT_END]->picture, title_win, gc, 0, 0, >+ pm[TBP_RIGHT_END]->width, title_height, >+ title_width - pm[TBP_RIGHT_END]->width, 0); >+} >+ >+#endif /* FANCY_TITLEBARS */ >+ > /* rules to get button state */ > static enum ButtonState get_button_state( > Bool has_focus, Bool toggled, Window w) >@@ -1029,6 +1212,7 @@ > Window expose_win, XRectangle *rclip) > { > int i; >+ int left1right0; > Bool is_lowest = True; > Pixmap *pass_bg_pixmap; > >@@ -1042,8 +1226,10 @@ > > for (i = 0; i < NUMBER_OF_BUTTONS; i++) > { >- if (t->button_w[i] != None && (((i & 1) && i / 2 < Scr.nr_right_buttons) || >- (!(i & 1) && i / 2 < Scr.nr_left_buttons))) >+ left1right0 = !(i&1); >+ if (t->button_w[i] != None && >+ ((!left1right0 && i/2 < Scr.nr_right_buttons) || >+ (left1right0 && i/2 < Scr.nr_left_buttons))) > { > mwm_flags stateflags = > TB_MWM_DECOR_FLAGS(GetDecor(t, buttons[i])); >@@ -1097,8 +1283,8 @@ > DrawButton(t, t->button_w[i], t->title_g.height, t->title_g.height, > tsdf, cd->relief_gc, cd->shadow_gc, > cd->fore_color, cd->back_color, is_lowest, >- TB_MWM_DECOR_FLAGS(GetDecor(t, buttons[i])), 1, NULL, >- pass_bg_pixmap); >+ TB_MWM_DECOR_FLAGS(GetDecor(t, buttons[i])), >+ left1right0, NULL, pass_bg_pixmap); > is_lowest = False; > } > } >@@ -1110,8 +1296,8 @@ > DrawButton(t, t->button_w[i], t->title_g.height, t->title_g.height, > df, cd->relief_gc, cd->shadow_gc, > cd->fore_color, cd->back_color, is_lowest, >- TB_MWM_DECOR_FLAGS(GetDecor(t, buttons[i])), 1, NULL, >- pass_bg_pixmap); >+ TB_MWM_DECOR_FLAGS(GetDecor(t, buttons[i])), left1right0, >+ NULL, pass_bg_pixmap); > is_lowest = False; > } > >@@ -1276,6 +1462,11 @@ > /* draw compound titlebar (veliaa@rpi.edu) */ > Bool is_lowest = True; > >+#ifdef FANCY_TITLEBARS >+ if (df->style.face_type == MultiPixmap) >+ DrawMultiPixmapTitlebar(t, df); >+ else >+#endif > if (PressedW == t->title_w) > { > #ifdef MULTISTYLE >@@ -1319,6 +1510,11 @@ > break; > } > >+#ifdef FANCY_TITLEBARS >+ if (TB_STATE(GetDecor(t, titlebar))[title_state].style.face_type >+ != MultiPixmap) >+#endif >+ { > #ifdef I18N_MB > if(t->name != (char *)NULL) > XmbDrawString(dpy, t->title_w, t->title_font.fontset, >@@ -1329,6 +1525,7 @@ > XDrawString(dpy, t->title_w, Scr.TitleGC, hor_off, > t->title_font.y + 1, t->name, strlen(t->name)); > #endif >+ } > } > > /* >diff -urN fvwm-2.4.7.orig/fvwm/builtins.c fvwm-2.4.7/fvwm/builtins.c >--- fvwm-2.4.7.orig/fvwm/builtins.c Tue Oct 30 19:16:52 2001 >+++ fvwm-2.4.7/fvwm/builtins.c Wed May 15 08:59:28 2002 >@@ -63,6 +63,9 @@ > > static char *ReadTitleButton( > char *s, TitleButton *tb, Boolean append, int button); >+#ifdef FANCY_TITLEBARS >+static char *ReadMultiPixmapDecor(char *s, DecorFace *df); >+#endif > static void DestroyFvwmDecor(FvwmDecor *decor); > > extern float rgpctMovementDefault[32]; >@@ -1401,6 +1404,10 @@ > > void FreeDecorFace(Display *dpy, DecorFace *df) > { >+#ifdef FANCY_TITLEBARS >+ int i; >+#endif >+ > switch (DFS_FACE_TYPE(df->style)) > { > case GradientButton: >@@ -1418,6 +1425,18 @@ > DestroyPicture(dpy, df->u.p); > break; > >+#ifdef FANCY_TITLEBARS >+ case MultiPixmap: >+ if (df->u.multi_pixmaps) { >+ for (i=0; i < NUM_TB_PIXMAPS; i++) { >+ if (df->u.multi_pixmaps[i]) >+ DestroyPicture(dpy, df->u.multi_pixmaps[i]); >+ } >+ free(df->u.multi_pixmaps); >+ } >+ break; >+#endif >+ > case VectorButton: > case DefaultVectorButton: > if (df->u.vector.x) >@@ -1649,6 +1668,19 @@ > else > DFS_FACE_TYPE(df->style) = PixmapButton; > } >+#ifdef FANCY_TITLEBARS >+ else if (strncasecmp(style,"MultiPixmap",11)==0) { >+ if (button != -1) { >+ if (verbose) >+ fvwm_msg(ERR, "ReadDecorFace", >+ "MultiPixmap is only valid for TitleStyle"); >+ return False; >+ } >+ s = ReadMultiPixmapDecor(s, df); >+ if (!s) >+ return False; >+ } >+#endif > #ifdef MINI_ICONS > else if (strncasecmp (style, "MiniIcon", 8) == 0) > { >@@ -1956,6 +1988,78 @@ > return end; > } > >+#ifdef FANCY_TITLEBARS >+/***************************************************************************** >+ * >+ * Reads a multi-pixmap titlebar config. (tril@igs.net) >+ * >+ ****************************************************************************/ >+static char *ReadMultiPixmapDecor(char *s, DecorFace *df) >+{ >+ static char *pm_names[NUM_TB_PIXMAPS+1] = { >+ "Main", >+ "LeftMain", >+ "RightMain", >+ "UnderText", >+ "LeftOfText", >+ "RightOfText", >+ "LeftEnd", >+ "RightEnd", >+ "Buttons", >+ "LeftButtons", >+ "RightButtons", >+ NULL >+ }; >+ Picture **pm; >+ char *token; >+ Bool stretched; >+ int pm_id, i; >+ >+ df->style.face_type = MultiPixmap; >+ df->u.multi_pixmaps = pm = >+ (Picture**)safecalloc(NUM_TB_PIXMAPS, sizeof(Picture*)); >+ >+ s = GetNextTokenIndex(s, pm_names, 0, &pm_id); >+ while (pm_id >= 0) { >+ s = DoPeekToken(s, &token, ",()", NULL, NULL); >+ stretched = False; >+ if (StrEquals(token, "stretched")) { >+ stretched = True; >+ s = DoPeekToken(s, &token, ",", NULL, NULL); >+ } >+ else if (StrEquals(token, "tiled")) >+ s = DoPeekToken(s, &token, ",", NULL, NULL); >+ if (!token) >+ break; >+ if (pm[pm_id]) { >+ fvwm_msg(WARN, "ReadMultiPixmapDecor", >+ "Ignoring already-specified %s pixmap", pm_names[i]); >+ continue; >+ } >+ if (stretched) >+ df->u.multi_stretch_flags |= (1 << pm_id); >+ pm[pm_id] = CachePicture(dpy, Scr.NoFocusWin, NULL, token, Scr.ColorLimit); >+ if (!pm[pm_id]) >+ fvwm_msg(ERR, "ReadMultiPixmapDecor", "Pixmap '%s' could not be loaded", >+ token); >+ s = GetNextTokenIndex(s, pm_names, 0, &pm_id); >+ } >+ >+ if (!pm[TBP_MAIN] && !(pm[TBP_LEFT_MAIN] && pm[TBP_RIGHT_MAIN])) { >+ fvwm_msg(ERR, "ReadMultiPixmapDecor", >+ "No Main pixmap found for TitleStyle MultiPixmap " >+ "(you must specify either Main, or both LeftMain and RightMain)"); >+ for (i=0; i < NUM_TB_PIXMAPS; i++) { >+ if (pm[i]) >+ DestroyPicture(dpy, pm[i]); >+ } >+ free(pm); >+ return NULL; >+ } >+ >+ return s; >+} >+#endif /* FANCY_TITLEBARS */ > > #ifdef USEDECOR > /***************************************************************************** >diff -urN fvwm-2.4.7.orig/fvwm/fvwm2.1 fvwm-2.4.7/fvwm/fvwm2.1 >--- fvwm-2.4.7.orig/fvwm/fvwm2.1 Thu Apr 11 13:15:04 2002 >+++ fvwm-2.4.7/fvwm/fvwm2.1 Wed May 15 08:59:27 2002 >@@ -6306,7 +6306,46 @@ > ButtonStyle All ActiveUp (-- flat) Inactive \\ > (-- flat) > .EE >+If fvwm is compiled with the FANCY_TITLEBARS option enabled, an additional >+TitleStyle is available: MultiPixmap. This allows you to specify different >+pixmaps for different parts of the titlebar. Some of them are tiled or >+stretched to fit a particular space; others are discrete "transition" pixmaps >+which are not resized in any way. The definable pixmaps are: >+.EX >+- Main (tiled/stretched): The main titlebar pixmap >+- LeftMain (tiled/stretched): Left of title text >+- RightMain (tiled/stretched): Right of title text >+- UnderText (tiled/stretched): Underneath title text >+- LeftOfText: Pixmap just to the left of the title text >+- RightOfText: Pixmap just to the right of the title text >+- LeftEnd: Pixmap at the far left end of the titlebar >+ (just before buttons) >+- RightEnd: Pixmap at the far right end of the titlebar >+ (just before buttons) >+- Buttons (tiled): Tiled under buttons in case of >+ UseTitleStyle >+- LeftButtons (tiled): Tiled under left buttons in case of >+ UseTitleStyle >+- RightButtons (tiled): Tiled under right buttons in case of >+ UseTitleStyle >+.EE >+None of these are mandatory except for Main (or, if you don't define Main, >+you must define both LeftMain and RightMain). If no "Buttons" pixmaps are >+defined and UseTitleStyle is specified for one or more buttons, Main, >+LeftMain, or RightMain will be used as appropriate. > >+The syntax for this style type is: >+.EX >+MultiPixmap <section> (<flag>) <pixmap filename>, ... >+.EE >+continuing for whatever pixmaps you want to define. By default, all >+non-transition pixmaps are tiled. If you want one stretched instead (this is >+allowed for Main, LeftMain, RightMain, and UnderText), add "(stretched)" after >+the section name: >+.EX >+MultiPixmap Main (stretched) foo.xpm, UnderText bar.xpm >+.EE >+Otherwise you can omit (<flag>), as shown with UnderText. > .TP > .BI "UpdateDecor [" decor "]" > This command is kept mainly for backwards compatibility. Since >diff -urN fvwm-2.4.7.orig/fvwm/fvwm2.1.orig fvwm-2.4.7/fvwm/fvwm2.1.orig >--- fvwm-2.4.7.orig/fvwm/fvwm2.1.orig Thu Jan 1 01:00:00 1970 >+++ fvwm-2.4.7/fvwm/fvwm2.1.orig Thu Apr 11 13:15:04 2002 >@@ -0,0 +1,7757 @@ >+.\" Formatting instructions for the fvwm man page: >+.\" >+.\" - Do not use \f... formatting instructions >+.\" unless you have to, see below. >+.\" - Avoid single and double quotes wherever possible. >+.\" >+.\" For further details, please refer to the Linux Man-Page how-to. >+.\" >+.\" context typeface example >+.\" ---------------------------------- -------------- ----------------- >+.\" filenames: italics (.I) .I .fvwm2rc >+.\" command line options of fvwm2 cmd: bold (.B) .B \-cmd >+.\" arguments of command line options: italics (.I) .BI \-cmd command >+.\" built in commands: bold (.B) .B Move >+.\" references to built in commands: bold (.B) .RB See Move >+.\" references to man page sections: bold (.B) .RB See SYNOPSIS >+.\" references to style options: italics (.I) .RI See Lenience >+.\" built in command options: italics (.I) .BI "Move " "0 0" >+.\" command syntax: bold/ita. (.BI) .BI "Move [" "x y" "]" >+.\" environment variables: italics (.I) .I $DISPLAY >+.\" key names: small (.SM) .SM Tab >+.\" style names and strings: double quotes "stylename", "x" >+.\" single characters: single quotes '@' >+.\" module names: bold (.B) .B FvwmTheme >+.\" links to web pages: bold (.B) .B http://fvwm.org >+.\" acronyms: small (.SM) .SM ICCCM >+.\" >+.\" >+.\" The name fvwm is written in lower case throughout this man >+.\" page. >+.\" >+.\" Note that the word "will" is rarely correct in a man page or >+.\" any document. Describe what fvwm does, not what it will do, >+.\" even if you haven't written the feature yet. dje 2/3/01 >+.\" (3/Feb/2001). >+.\" >+.\" A note to everyone who needs to write dates. Don't use 2/3/01 >+.\" notation, a non-american person simply can't parse such >+.\" sequence of digits. Please use 3-Feb-2001 or 2001-02-03 forms. >+.\" migo 16/May/2001. >+.\" >+.\" A note about the rule against \f... formatting. On Solaris, >+.\" AIX, and HPUX the ".BI" type commands are limited to 6 >+.\" arguments. use \f... formatting in that case. See the lines >+.\" formatted with ".IP". >+.\" dje 15/June/2001. >+.\" >+.\" @(#)fvwm-2.4.7 11 Apr 2002 >+.de EX \"Begin example >+.ne 5 >+.if n .sp 1 >+.if t .sp .5 >+.nf >+.in +.5i >+.. >+.de EE >+.fi >+.in -.5i >+.if n .sp 1 >+.if t .sp .5 >+.. >+.ta .3i .6i .9i 1.2i 1.5i 1.8i >+.TH FVWM2 1 "11 Apr 2002" >+.UC >+.SH NAME >+ >+fvwm2 \- F(?) Virtual Window Manager (version 2) for X11 >+.SH SYNOPSIS >+ >+.B fvwm2 >+.RB [ \-blackout ] >+.RB [ \-clientId >+.IR id ] >+.RB [ \-cmd >+.IR config_command ] >+.RB [ \-d >+.IR displayname ] >+.RB [ \-debug ] >+.RB [ \-debug_stack_ring ] >+.RB [ \-f >+.IR config_file ] >+.RB [ \-h ] >+.RB [ \-replace ] >+.RB [ \-restore >+.IR state_file ] >+.RB [ \-s ] >+.RB [ \-version ] >+.RB [ \-visual >+.IR visual_class ] >+.RB [ \-visualId >+.IR id ] >+ >+.SH DESCRIPTION >+ >+Fvwm is a window manager for X11. It is designed to minimize >+memory consumption, provide a 3D look to window frames, and a >+virtual desktop. >+ >+Note that there are several window managers around that have >+"fvwm" in their name. In the past, version 2.x of fvwm was >+commonly called fvwm2 to distinguish it from the former version >+1.x (fvwm or even fvwm1). Since version 1.x has been replaced by >+version 2.x a long time ago we simply call version 2.x and all >+versions to come, fvwm, throughout this document, although the >+executable program is named fvwm2. There is an fvwm offspring >+called fvwm95. Although it is very similar to older versions of >+fvwm version 2 it is technically a different window manager that >+has been developed by different people. The main goal of fvwm95 >+was to supply a Windows 95 like look and feel. Since then fvwm >+has been greatly enhanced and only very few features of fvwm95 can >+not be imitated by fvwm. No active development has been going on >+for fvwm95 for several years now. Unfortunately Red Hat (a >+popular Linux distributor) has a pre-configured fvwm package based >+on fvwm version 2.x that is called fvwm95 too. >+ >+Fvwm provides both a large >+.I virtual desktop >+and >+.I multiple disjoint desktops >+which can be used separately or together. The virtual desktop >+allows you to pretend that your video screen is really quite >+large, and you can scroll around within the desktop. The multiple >+disjoint desktops allow you to pretend that you really have >+several screens to work at, but each screen is completely >+unrelated to the others. >+ >+Fvwm provides >+.I keyboard accelerators >+which allow you to perform most window-manager functions, >+including moving and resizing windows, and operating the menus, >+using keyboard shortcuts. >+ >+Fvwm has also blurred the distinction between configuration >+commands and built-in commands that most window-managers make. >+Configuration commands typically set fonts, colors, menu contents, >+key and mouse function bindings, while built-in commands typically >+do things like raise and lower windows. Fvwm makes no such >+distinction, and allows, to the extent that is practical, anything >+to be changed at any time. >+ >+Other noteworthy differences between Fvwm and other X11 window >+managers are the introduction of the >+.I SloppyFocus " and " NeverFocus >+focus methods. Focus policy can be specified for individual >+windows. Windows using >+.I SloppyFocus >+acquire focus when the pointer moves into them and retain focus >+until some other window acquires it. Such windows do not lose >+focus when the pointer moves into the root window. The >+.I NeverFocus >+policy is provided for use with windows into which one never types >+(e.g. xclock, oclock, xbiff, xeyes, tuxeyes) - for example, if a >+SloppyFocus terminal window has focus, moving the cursor over a >+.I NeverFocus >+decoration window won't deprive the terminal of focus. >+ >+.SH OPTIONS >+ >+These are the command line options that are recognized by fvwm: >+.TP >+.BI "-blackout" >+This option is provided for backward compatibility only. Blacking >+out the screen during startup is not necessary anymore. >+.TP >+.BI "-clientId " id >+This option is used when fvwm is started by a session >+manager. Should not be used by a user. >+ >+.TP >+.BI "-cmd " config_command >+Causes fvwm to use >+.I config_command >+instead of >+.RB "'Read" >+.IR ".fvwm2rc'" >+as its initialization command. (Note that up to 10 >+.BR \-f " and " \-cmd >+parameters can be given, and they are executed in the order >+specified.) >+.TP >+.BI "-d " displayname >+Manage the display called >+.I displayname >+instead of the name obtained from the environment variable >+.IR "$DISPLAY" . >+.TP >+.BI "-debug" >+Puts X transactions in synchronous mode, which dramatically slows >+things down, but guarantees that fvwm's internal error messages >+are correct. Also causes fvwm to output debug messages while >+running. >+.TP >+.BI "-debug_stack_ring" >+Enables stack ring debugging. This option is only intended for >+internal debugging and should only be used by developers. >+.TP >+.BI "-f " config_file >+Causes fvwm to read >+.I config_file >+instead of >+.I .fvwm2rc >+as its initialization file. This is equivalent to >+.RB "-cmd 'Read" >+.IR "config_file'." >+. >+.TP >+.BI "-h" >+A short usage description is printed. >+.TP >+.BI "-replace" >+Try to take over from a previously running wm. This does not work >+unless the other wm is >+.SM ICCCM >+2.0 compliant. >+.TP >+.BI "-restore " state_file >+This option is used when fvwm is started by a session manager. >+Should not be used by a user. >+.TP >+.BI "-s" >+On a multi-screen display, run fvwm only on the screen named in >+the >+.I $DISPLAY >+environment variable or provided through the >+.B -d >+option. Normally, fvwm attempts to start up on all screens of a >+multi-screen display. >+.TP >+.BI "-version" >+Prints the version of fvwm to >+.IR stderr . >+Also prints an information about the compiled in support for >+readline, rplay, stroke, xpm, gnome hints, session management and >+multibyte characters. >+.TP >+.BI "-visual " visual_class >+Causes fvwm to use >+.I visual_class >+for the window borders and menus. >+.I visual_class >+can be "StaticGray", "GrayScale", "StaticColor", "PseudoColor", >+"TrueColor" or "DirectColor". >+.TP >+.BI "-visualId " id >+Causes fvwm to use >+.I id >+as the visualId for the window borders and menus. >+.I id >+can be specified as N for decimal or 0xN for hexadecimal. See man >+page of xdpyinfo for a list of supported visuals. >+ >+ >+.SH ANATOMY OF A WINDOW >+ >+Fvwm puts a decorative border around most windows. This border >+consists of a bar on each side and a small L-shaped section on >+each corner. There is an additional top bar called the title-bar >+which is used to display the name of the window. In addition, >+there are up to 10 title-bar buttons. The top, side, and bottom >+bars are collectively known as the side-bars. The corner pieces >+are called the frame. >+ >+Unless the standard defaults files are modified, pressing mouse >+button 1 in the title or side-bars begins a move operation on the >+window. Pressing button 1 in the corner frame pieces begins a >+resize operation. Pressing button 2 anywhere in the border brings >+up an extensive list of window operations. >+ >+Up to ten title-bar buttons may exist. Their use is completely >+user definable. The default configuration has a title-bar button >+on each side of the title-bar. The one on the left is used to >+bring up a list of window options, regardless of which mouse >+button is used. The one on the right is used to iconify the >+window. The number of title-bar buttons used depends on which >+ones have mouse actions bound to them. See the section on the >+.B Mouse >+command below. >+ >+ >+.SH THE VIRTUAL DESKTOP >+ >+Fvwm provides multiple virtual desktops for users who wish to use >+them. The screen is a viewport onto a >+.I desktop >+which may be larger than the screen. Several distinct desktops >+can be accessed (concept: one desktop for each project, or one >+desktop for each application, when view applications are >+distinct). Since each desktop can be larger than the physical >+screen, divided into m by n >+.I pages >+which are each the size of the physical screen, windows which are >+larger than the screen or large groups of related windows can >+easily be viewed. >+ >+The (m by n) size (i.e. number of pages) of the virtual desktops >+can be changed any time, by using the >+.B DeskTopSize >+built-in command. All virtual desktops must be (are) the same >+size. The total number of distinct desktops does not need to be >+specified, but is limited to approximately 4 billion total. All >+windows on a range of desktops can be viewed in the >+.BR FvwmPager , >+a miniature view of the desktops. The pager is an accessory >+program, called a module, which is not essential for the window >+manager to operate. Windows may also be listed, along with their >+geometries, in a window list, accessible as a pop-up menu, or as a >+separate window, called the >+.B FvwmWinList >+(another module). >+ >+Fvwm keeps the windows on the desktop in a layered stacking order; >+a window in a lower layer never obscures a window in a higher >+layer. The layer of a window can be changed by using the >+.B Layer >+command. The concept of layers is a generalization of the >+.I StaysOnTop >+flag of older fvwm versions. The >+.IR StaysOnTop " and " StaysPut >+.B Style >+options are now implemented by putting the windows in suitable >+layers and the previously missing >+.IB "StaysOnBottom " Style >+option has been added. >+ >+.B Sticky >+windows are windows which transcend the virtual desktop by >+"Sticking to the screen's glass". They always stay put on the >+screen. This is convenient for things like clocks and xbiff's, so >+you only need to run one such gadget and it always stays with you. >+Icons can also be made to stick to the glass, if desired. >+ >+Window geometries are specified relative to the current viewport. >+That is: >+.EX >+xterm -geometry +0+0 >+.EE >+creates a window in the upper-left hand corner of the visible >+portion of the screen. It is permissible to specify geometries >+which place windows on the virtual desktop, but off the screen. >+For example, if the visible screen is 1000 by 1000 pixels, and the >+desktop size is 3x3, and the current viewport is at the upper left >+hand corner of the desktop, invoking: >+.EX >+xterm -geometry +1000+1000 >+.EE >+places a window just off of the lower right hand corner of the >+screen. It can be found by moving the mouse to the lower right >+hand corner of the screen and waiting for it to scroll into view. >+A geometry specified as something like: >+.EX >+xterm -geometry -5-5 >+.EE >+places the window's lower right hand corner 5 pixels from the >+lower right corner of the visible portion of the screen. Not all >+applications support window geometries with negative offsets. >+Some applications place the window's upper right hand corner 5 >+pixels above and to the left of the upper left hand corner of the >+screen; others may do just plain bizarre things. >+ >+There are several ways to cause a window to map onto a desktop or >+page other than the currently active one. The geometry technique >+mentioned above (specifying x,y coordinates larger than the >+physical screen size), however, suffers from the limitation of >+being interpreted relative to the current viewport: the window may >+not consistently appear on a specific page, unless you always >+invoke the application from the same page. >+ >+A better way to place windows on a different page, screen or desk >+from the currently mapped viewport is to use the >+.IR StartsOnPage or StartsOnScreen >+style specification (the successors to the older >+.I StartsOnDesk >+style) in the >+.I .fvwm2rc >+configuration file. The placement is consistent: it does not >+depend on your current location on the virtual desktop. >+ >+Some applications that understand standard Xt command line >+arguments and X resources, like xterm and xfontsel, allow the user >+to specify the start-up desk or page on the command line: >+.EX >+xterm -xrm "*Desk:1" >+.EE >+starts an xterm on desk number 1; >+.EX >+xterm -xrm "*Page:3 2 1" >+.EE >+starts an xterm two pages to the right and one down from the upper >+left hand page of desk number 3. Not all applications understand >+the use of these options, however. You could achieve the same >+results with the following lines in your >+.I .Xdefaults >+file: >+.EX >+XTerm*Desk: 1 >+.EE >+or >+.EX >+XTerm*Page: 3 2 1 >+.EE >+ >+ >+.SH USE ON MULTI-SCREEN DISPLAYS >+ >+If the >+.B -s >+command line argument is not given, fvwm automatically starts up >+on every screen on the specified display. After fvwm starts each >+screen is treated independently. Restarts of fvwm need to be >+performed separately on each screen. The use of >+.EX >+ EdgeScroll 0 0 >+.EE >+is strongly recommended for multi-screen displays. You may need >+to quit on each screen to quit from the X session completely. >+This is not to be confused with Xinerama support. >+ >+ >+.SH XINERAMA SUPPORT >+ >+Fvwm supports the Xinerama extension of newer X servers which >+is similar to multi head support (multiple screens) but allows to >+move windows between screens. If Xinerama support has been >+compiled into fvwm, it is used whenever fvwm runs on an X server >+that supports and uses multiple screens via Xinerama. Without >+this option, the whole desktop is treated as one big screen. For >+example, menus might pop up right between two screens. The >+.BI EdgeResistance >+command allows to specify an explicit resistance value for moving >+windows over the screen edge between two Xinerama screens. >+Xinerama support can be enabled or disabled on the fly or from the >+configuration file with the >+.B Xinerama >+command. Many modules and commands work nicely with Xinerama >+displays. >+ >+Everywhere where a geometry in the usual X format can be supplied, >+fvwm's Xinerama extension allows to specify a screen in addition >+to the geometry (or even the screen alone). To do this, a '@' is >+added to the end of the geometry string followed by either the >+screen number or a letter. A number is taken as the number of the >+Xinerama screen to be used (as configured in the X server). The >+letter can be one of 'g' for the global screen (the rectangle that >+encloses all Xinerama screens), 'p' for the primary screen (see >+below), 'c' for the current screen (the one that currently >+contains the pointer). If the X server does not support Xinerama >+or only one screen is used, the screen bit is ignored. >+ >+.EX >+Style * IconBox 64x300-0-0@p >+.EE >+ >+Xinerama support can be configured to use a primary screen. Fwvm >+can be configured to place new windows and icons on this screen. >+The primary screen is screen 0 by default but can be changed with >+the >+.B XineramaPrimaryScreen >+command. >+ >+Xinerama support was designed to work out of the box with the same >+configurations file that would work on a single screen. It may >+not work too well if the involved screens use different screen >+resolutions. In this situation, windows may get stuck in the >+portion of the whole desktop that belongs to neither screen. If >+this happens, the windows or icons can be retrieved with the >+command >+ >+.EX >+All MoveToScreen >+.EE >+ >+that can be entered in an FvwmConsole window or with FvwmCommand. >+ >+For multi-screen implementations other than Xinerama, such as >+Single Logical Screen, it is possible to simulate a Xinerama >+configuration if the total screen seen by FVWM is made up of >+equal sized monitors in a rectangular grid. The commands >+.BR XineramaSls " and " XineramaSlsSize >+are used to configure this feature. >+ >+ >+.SH INITIALIZATION >+ >+During initialization, fvwm searches for a configuration file >+which describes key and button bindings, and many other >+things. The format of these files is described later. Fvwm first >+searches for configuration files using the command >+.EX >+.BI "Read " .fvwm2rc >+.EE >+This looks for >+.IR .fvwm2rc " in " >+.IR "$HOME/.fvwm" " or " "$FVWM_USERDIR" >+directories, as described in >+.B Read >+below. If this fails, fvwm also searches for this file in the >+.I $HOME >+directory or for >+.I system.fvwm2rc >+file in the system place. If a configuration file is not found, >+any mouse button or the >+.SM Help >+or >+.SM F1 >+keys on the root window brings up menus and forms that can create >+a starting configuration file. >+ >+Fvwm sets two environment variables which are inherited by its >+children. These are >+.I $DISPLAY >+which describes the display on which fvwm is running. >+.I $DISPLAY >+may be >+.I unix:0.0 >+or >+.IR ":0.0" , >+which doesn't work too well when passed through rsh to another >+machine, so >+.I $HOSTDISPLAY >+is set to a network-ready description of the display. >+.I $HOSTDISPLAY >+always uses the TCP/IP transport protocol (even for a local >+connection) so >+.I $DISPLAY >+should be used for local connections, as it may use Unix-domain >+sockets, which are faster. >+ >+If you want to start some applications or modules with fvwm, you >+can simply put >+.EX >+Exec app >+.EE >+or >+.EX >+Module FvwmXxx >+.EE >+into your >+.IR .fvwm2rc , >+but it is not recommended; do this only if you know what you are >+doing. It is usually critical to start applications or modules >+after >+.I .fvwm2rc >+is read, because it contains styles or module configurations which >+can affect window appearance and functionality. >+ >+The standard way to start applications or modules on fvwm's start >+up is to add them to an initialization function (usually >+.BR StartFunction " or " InitFunction ). >+This way they are only started after fvwm reads the entire >+.IR .fvwm2rc . >+ >+Fvwm has three special functions for initialization: >+.BR StartFunction , >+which is executed on startups and restarts; >+.BR InitFunction " and " RestartFunction , >+which are executed during initialization and restarts >+(respectively) just after StartFunction. These functions may be >+customized in a user's >+.I .fvwm2rc >+file via the >+.B AddToFunc >+command (described later) to start up modules, xterms, or whatever >+you'd like to have started by fvwm. >+ >+Fvwm has also a special exit function: >+. BR ExitFunction , >+executed when exiting or restarting before actually quitting. >+It could be used to explicitly kill modules, etc. >+ >+If fvwm is run under a session manager, functions >+.BR SessionInitFunction " and " SessionRestartFunction >+are executed instead of InitFunction and RestartFunction. >+This helps to define the user's >+.I .fvwm2rc >+file to be good for both running under a session manager and >+without it. Generally it is a bad idea to start xterms or other >+applications in "Session*" functions. Also someone can decide to >+start different modules while running under a session manager or >+not. For the similar purposes >+. B SessionExitFunction >+is used instead of ExitFunction. >+.EX >+DestroyFunc StartFunction >+AddToFunc StartFunction >+ + I ModuleSynchronous FvwmTheme >+ + I Module FvwmPager * * >+ + I Module FvwmButtons >+ >+DestroyFunc InitFunction >+AddToFunc InitFunction >+ + I Module FvwmBanner >+ + I Module FvwmTaskBar >+ + I xsetroot -solid cyan >+ + I Exec xterm >+ + I Exec netscape >+ >+DestroyFunc RestartFunction >+AddToFunc RestartFunction >+ + I Module FvwmTaskBar >+ >+DestroyFunc SessionInitFunction >+AddToFunc SessionInitFunction >+ + I Module FvwmBanner >+ >+DestroyFunc SessionRestartFunction >+AddToFunc SessionRestartFunction >+ + I Nop >+.EE >+You don't need to define all special functions if some are empty. >+ >+.SH COMPILATION OPTIONS >+ >+Fvwm has a number of compile-time options. If you have trouble >+using a certain command or feature, check to see if support for it >+was included at compile time. Optional features are described in >+the >+.I config.h >+file that is generated during compilation. >+ >+.SH ICONS >+ >+The basic fvwm configuration uses monochrome bitmap icons. If >+.B XPM >+extensions are compiled in, then color icons can be used. In order >+to use these options you need the XPM package, as described in the >+.I INSTALL.fvwm >+file. >+ >+If both the >+.BR SHAPE " and " XPM >+options are compiled in you get shaped color icons, which are very >+spiffy. >+ >+.SH MODULES >+ >+A module is a separate program which runs as a separate Unix >+process but transmits commands to fvwm to execute. Users can >+write their own modules to do any weird or bizarre manipulations >+without bloating or affecting the integrity of fvwm itself. >+ >+Modules must be spawned by fvwm so that it can set up two pipes >+for fvwm and the module to communicate with. The pipes are >+already open for the module when it starts and the file >+descriptors for the pipes are provided as command line arguments. >+ >+Modules can be spawned during fvwm at any time during the X >+session by use of the >+.B Module >+built-in command. Modules can exist for the duration of the X >+session, or can perform a single task and exit. If the module is >+still active when fvwm is told to quit, then fvwm closes the >+communication pipes and waits to receive a SIGCHLD from the >+module, indicating that it has detected the pipe closure and has >+exited. If modules fail to detect the pipe closure fvwm exits >+after approximately 30 seconds anyway. The number of >+simultaneously executing modules is limited by the operating >+system's maximum number of simultaneously open files, usually >+between 60 and 256. >+ >+Modules simply transmit text commands to the fvwm built-in command >+engine. Text commands are formatted just as in the case of a >+mouse binding in the >+.I .fvwm2rc >+setup file. Certain auxiliary information is also transmitted, as >+in the sample module >+.BR FvwmButtons . >+The >+.B FvwmButtons >+module is documented in its own man page. >+ >+Please refer to the >+.B "MODULE COMMANDS" >+section for details. >+ >+.SH ICCCM COMPLIANCE >+ >+Fvwm attempts to be >+.SM ICCCM >+2.0 compliant. In addition, >+.SM ICCCM >+states that it should be possible for applications to receive any >+keystroke, which is not consistent with the keyboard shortcut >+approach used in fvwm and most other window managers. In >+particular you cannot have the same keyboard shortcuts working >+with your fvwm and another fvwm running within Xnest (a nested X >+server running in a window). The same problem exists with mouse >+bindings. >+ >+The >+.SM ICCCM >+states that windows possessing the property >+.EX >+WM_HINTS(WM_HINTS): >+ Client accepts input or input focus: False >+.EE >+should not be given the keyboard input focus by the window >+manager. These windows can take the input focus by themselves, >+however. A number of applications set this property, and yet >+expect the window-manager to give them the keyboard focus anyway, >+so fvwm provides a window-style, >+.IR Lenience ", " >+which allows fvwm to overlook this >+.SM ICCCM >+rule. Even with this window-style it is not guaranteed that the >+application accepts focus. >+ >+The differences between >+.SM ICCCM >+1.1 and 2.0 include the ability to take over from a running >+.SM ICCCM >+2.0 compliant window manager; thus >+.EX >+fvwm2; vi .fvwm2rc; fvwm2 -replace >+.EE >+resembles the >+.B Restart >+command. It is not exactly the same, since killing the previously >+running wm may terminate your X session, if the wm was started as >+the last client in your >+.IR .Xclients " or " .Xsession >+file. >+ >+Further additions are support for client-side colormap >+installation (see the .SM ICCCM for details) and the urgency hint. >+Clients can set this hint in the WM_HINTS property of their window >+and expect the window manager to attract the users attention to >+the window. Fvwm has two re-definable functions for this purpose, >+"UrgencyFunc" and "UrgencyDoneFunc", which are executed when the >+flag is set/cleared. Their default definitions are: >+.EX >+AddToFunc UrgencyFunc >+ + I Iconify off >+ + I FlipFocus >+ + I Raise >+ + I WarpToWindow 5p 5p >+AddToFunc UrgencyDoneFunc >+ + I Nop >+.EE >+ >+.SH GNOME COMPLIANCE >+ >+Fvwm attempts to be >+.SM GNOME >+compliant. Check >+.B http://www.gnome.org >+for what that may mean. >+.SM GNOME >+support is a compile time option which is on by default. To >+disable GNOME hints for some or all windows, the >+.I GNOMEIgnoreHints >+style can be used. >+ >+.SH MWM COMPATIBILITY >+ >+Fvwm provides options to emulate Motif Window Manager (Mwm) as >+well as possible. Please refer to the >+.B Emulate >+command as well as to the Mwm specific options of the >+.BR Style " and " MenuStyle >+commands for details. >+ >+.SH OPEN LOOK and XVIEW COMPATIBILITY >+Fvwm supports all the Open Look decoration hints (except >+pushpins). Most (perhaps all) Open Look applications have a >+strange notion of keyboard focus handling. Although a lot of work >+went into fvwm to work well with these, you may still encounter >+problems. Should you use any such application, please add the >+following line to your .fvwm2rc: >+.EX >+Style * OLDecor >+.EE >+ >+.SH M4 PREPROCESSING >+ >+.PP >+M4 pre-processing is handled by a module in fvwm. To get more >+details, try man >+.BR FvwmM4 . >+In short, if you want fvwm to parse your files with m4, then >+replace the command >+.B Read >+with >+.B FvwmM4 >+in your >+.I .fvwm2rc >+file (if it appears at all), and start fvwm with the command >+.EX >+fvwm2 -cmd "FvwmM4 .fvwm2rc" >+.EE >+ >+.SH CPP PREPROCESSING >+ >+.PP >+Cpp is the C-language pre-processor. fvwm offers cpp processing >+which mirrors the m4 pre-processing. To find out about it, >+re-read the M4 section above, but replace "m4" with "cpp". >+ >+.SH AUTO-RAISE >+ >+.PP >+Windows can be automatically raised when it receives focus, or >+some number of milliseconds after it receives focus, by using the >+auto-raise module, >+.BR FvwmAuto . >+ >+.SH CONFIGURATION FILES >+ >+The configuration file is used to describe mouse and button >+bindings, colors, the virtual display size, and related items. >+The initialization configuration file is typically called >+.IR .fvwm2rc . >+By using the >+.B Read >+built-in, it is easy to read in new configuration files as you go. >+ >+Lines beginning with '#' are ignored by fvwm. Lines starting with >+'*' are expected to contain module configuration commands (rather >+than configuration commands for fvwm itself). Like in shell >+scripts embedded newlines in a configuration file line can be >+quoted by preceding them with a backslash. All lines linked in >+this fashion are treated as a single line. The newline itself is >+ignored. >+ >+Fvwm makes no distinction between configuration commands and >+built-in commands, so anything mentioned in the built-in commands >+section can be placed on a line by itself for fvwm to execute as >+it reads the configuration file, or it can be placed as an >+executable command in a menu or bound to a mouse button or a >+keyboard key. It is left as an exercise for the user to decide >+which function make sense for initialization and which ones make >+sense for run-time. >+ >+ >+.SH SUPPLIED CONFIGURATION >+ >+A sample configuration file, >+.IR .fvwm2rc , >+is supplied with the fvwm distribution. It is well commented and >+can be used as a source of examples for fvwm configuration. >+ >+ >+.\" .SH INTERNATIONALIZATION >+.\" Internationalized fvwm enables to display not only LATIN-1 >+.\" characters but also multi byte characters such as Japanese, >+.\" Korean, etc. You should set up your environment variable >+.\" .IR LC_TYPE " or " LANG , >+.\" to enable this feature. Also, you should specify proper >+.\" .I FONTSET >+.\" instead of >+.\" .IR FONT . >+.\" Note that no catalog-file or input-methods are implemented. >+ >+.SH KEYBOARD SHORTCUTS >+ >+Almost all window manager operations can be performed from the >+keyboard so mouse-less operation should be possible. In addition >+to scrolling around the virtual desktop by binding the >+.B Scroll >+built-in to appropriate keys, >+.BR Popup ", " Move ", " Resize ", " >+and most other built-ins can be bound to keys. Once a built in >+function is started the pointer is moved by using the up, down, >+left, and right arrows, and the action is terminated by pressing >+return. Holding down the >+.SM Shift >+key causes the pointer movement to go in larger steps and holding >+down the >+.SM control >+key causes the cursor movement to go in smaller steps. Standard >+emacs and vi cursor movement controls ( >+.SM Ctrl-n, >+.SM Ctrl-p, >+.SM Ctrl-f, >+.SM Ctrl-b, >+and >+.SM Ctrl-j, >+.SM Ctrl-k, >+.SM Ctrl-h, >+.SM Ctrl-l >+) can be used instead of the arrow keys. >+ >+ >+.SH SESSION MANAGEMENT >+ >+Fvwm supports session management according to the X Session >+Management Protocol. It saves and restores window position, size, >+stacking order, desk, stickiness, shadedness, maximizedness, >+iconifiedness for all windows. Furthermore, some global state is >+saved. >+ >+Fvwm doesn't save any information regarding styles, decors, >+functions or menus. If you change any on these resources during a >+session (e.g. by issuing >+.B Style >+commands or by using various modules), these changes are lost >+after saving and restarting the session. To become permanent, >+such changes have to be added to the configuration file. >+ >+Note further that the current implementation has the following >+anomaly when used on a multi-screen display: Starting fvwm for the >+first time, fvwm manages all screens by forking a copy of itself >+for each screen. Every copy knows its parent and issuing a >+.B Quit >+command to any instance of fvwm kills the master and thus all >+copies of fvwm. When you save and restart the session, the >+session manager brings up a copy of fvwm on each screen, but this >+time they are started as individual instances managing one screen >+only. Thus a >+.B Quit >+kills only the copy it was sent to. This is probably not a very >+serious problem, since with session management, you are supposed >+to quit a session through the session manager anyway. If it is >+really needed, >+.EX >+Exec exec killall fvwm2 >+.EE >+still kills all copies of fvwm. Your system must have the >+.B killall >+command though. >+ >+.SH BOOLEAN ARGUMENTS >+ >+A number of commands take one or several boolean arguments. These >+take a few equivalent inputs: "yes", "on", "true", "t" and "y" all >+evaluate to true while "no", "off", "false", "f" and "n" evaluate >+to false. Some commands allow "toggle" too which means that the >+feature is disabled if it is currently enabled and vice versa. >+ >+.SH BUILT IN KEY AND MOUSE BINDINGS >+ >+The following commands are built-in to fvwm: >+.EX >+Key Help R A Popup MenuFvwmRoot >+Key F1 R A Popup MenuFvwmRoot >+Key Tab A M WindowList Root c c NoDeskSort >+Key Escape A MC EscapeFunc >+Mouse 0 R N Menu MenuFvwmRoot >+Mouse 1 TS A FuncFvwmRaiseLowerX Move >+Mouse 1 F A FuncFvwmRaiseLowerX Resize >+AddToFunc FuncFvwmRaiseLowerX I Raise >++ M $0 >++ D Lower >+.EE >+The >+.SM Help >+and >+.SM F1 >+keys invoke a built-in menu that fvwm creates. This is primarily >+for new users that have not created their own configuration >+file. Either key on the root (background) window pops up an menu >+to help you get started. >+ >+The >+.SM Tab >+key pressed anywhere with the >+.SM Meta >+key (same as the >+.SM Alt >+key on PC keyboards) held down pop-ups a window list. >+ >+Mouse button 1 on the title-bar or side frame can move, raise or >+lower a window. >+ >+Mouse button 1 on the window corners can resize, raise or lower a >+window. >+ >+You can override or remove these bindings. To remove the window >+list binding, use this: >+.EX >+Key Tab A M - >+.EE >+ >+.SH BUILT IN COMMANDS >+ >+Fvwm supports a set of built-in functions which can be bound to >+keyboard or mouse buttons. If fvwm expects to find a built-in >+function in a command, but fails, it checks to see if the >+specified command should have been >+.EX >+Function (rest of command) >+.EE >+or >+.EX >+Module (rest of command) >+.EE >+This allows complex functions or modules to be invoked in a manner >+which is fairly transparent to the configuration file. >+ >+Example: the >+.I .fvwm2rc >+file contains the line >+.EX >+HelpMe >+.EE >+Fvwm looks for a built-in command called "HelpMe", and fails. >+Next it looks for a user-defined complex function called "HelpMe". >+If no such user defined function exists, Fvwm tries to execute a >+module called "HelpMe". >+ >+Note: There are many commands that affect look and feel of >+specific, some or all windows, like >+.BR Style ", " Mouse ", the " FvwmTheme >+module and many others. For performance reasons such changes are >+not applied immediately but only when fvwm is idle, i.e. no user >+interaction or module input is pending. Specifically, new >+.B Style >+options that are set in a function are not applied until after the >+function has completed. This can sometimes lead to unwanted >+effects. >+ >+To force that all pending changes are applied immediately, use the >+.BR UpdateStyles ", " Refresh " or " RefreshWindow >+commands. >+ >+.SS QUOTING >+ >+Quotes are required only when needed to make fvwm consider two or >+more words to be a single argument. Unnecessary quoting is >+allowed. If you want a quote character in your text, you must >+escape it by using the backslash character. For example, if you >+have a pop-up menu called "Window-Ops", then you don't need >+quotes: >+.EX >+Popup Window-Ops >+.EE >+but if you replace the dash with a space, then you need >+quotes: >+.EX >+Popup "Window Ops" >+.EE >+The supported quoting characters are double quotes, single quotes >+and reverse single quotes. All three kinds of quotes are treated >+in the same way. Single characters can be quoted with a preceding >+backslash. Quoting single characters works even inside other >+kinds of quotes. >+ >+.SS COMMAND EXPANSION >+ >+Whenever a fvwm command line is executed, fvwm performs parameter >+expansion. A parameter is a '$' followed by a single letter or a >+word enclosed in brackets ($[...]). If fvwm encounters an >+unquoted parameter on the command line it expands it to a string >+indicated by the parameter name. Unknown parameters are left >+untouched. Parameter expansion is performed before quoting. To >+quote a '$' use "$$". Note that module configuration lines >+(i.e. lines beginning with '*') are not fully expanded; for >+backward compatibility single alphabetic-letter parameters (like >+"$d" or "$n") are not expanded in these lines. >+ >+The general idea is to expand single letter parameters as soon as >+possible. So a "$d" is expanded immediately when read by the >+parser, but "$3" is only expanded in the context of a complex >+function with at least four parameters. Otherwise it is left >+untouched. Similarly, "$c" is only expanded in the context of a >+window. >+ >+Parameter expansion in the >+.BR + >+command is different than in normal commands. If the command is >+adding to a function, single letter parameters are expanded >+normally which is often not what was intended. To suppress >+expansion the '$' has to be doubled. Parameters enclosed in >+brackets are protected from parameter expansion in these commands >+so the '$' must not be doubled. >+ >+Example: >+ >+.EX >+# Print the current desk number, horizontal >+# page and the window's class. >+Echo $d $[page.nx] $c >+# But a function that prints $d needs $$, >+# but not before $[page.nx] or $c: >+AddToFunc PrintDeskNumber >++ I Echo $$d $[page.nx] $c >+.EE >+ >+Note: If this funtion is called outside a window context, it will >+print "$c" instead of the class name. It is usually not enough to >+have the pointer over a window to have a context window. To force >+using the window with the focus, the >+.B Current >+command can be used: >+.EX >+Current Echo $d $[page.nx] $c >+.EE >+ >+The parameters known by fvwm are: >+ >+.in +.5i >+$$ >+.in +.3i >+A literal '$'. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$. >+.in +.3i >+The absolute directory of the currently Read file. Intended for >+creating relative and relocatable configuration trees. If used >+outside of any read file, the returned value is '.'. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$c >+.in +.3i >+The window's resource class name or "$c" if no window is >+associated with the command. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$d >+.in +.3i >+The current desk number. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$n >+.in +.3i >+The window's name or "$n" if no window is associated with the >+command. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$r >+.in +.3i >+The window's resource name or "$r" if no window is associated with >+the command. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$v >+.in +.3i >+The first line printed by the -version command line option. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$w >+.in +.3i >+The window-id (expressed in hex, e.g. 0x10023c) of the window the >+command was called for or "$w" if no window is associated with the >+command. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$x >+.in +.3i >+The x coordinate of the current viewport. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$y >+.in +.3i >+The y coordinate of the current viewport. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$0 to $9 >+.in +.3i >+The positional parameters given to a complex function (a function >+that has been defined with the >+.B AddToFunc >+command). "$0" is replaced with the first parameter, "$1" with >+the second parameter and so on. If the corresponding parameter is >+undefined, the "$..." is deleted from the command line. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$* >+.in +.3i >+All positional parameters given to a complex function. This >+includes parameters that follow after "$9". >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[vp.x] >+$[vp.y] >+$[vp.width] >+$[vp.height] >+.in +.3i >+Either coordinate or the width or height of the current viewport. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[desk.width] >+$[desk.height] >+.in +.3i >+The width or height of the whole desktop, i.e. the width or height >+multiplied by the number of pages in x or y direction. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[page.nx] >+$[page.ny] >+.in +.3i >+The current page numbers, by X and Y axes, starting from 0. >+.IR page " is equivalent to " area " in the GNOME terminology." >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[w.x] >+$[w.y] >+$[w.width] >+$[w.height] >+.in +.3i >+Either coordinate or the width or height of the current window if >+it is not iconified. If no window is associated with the command >+or the window is iconified, the string is left as is. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[screen] >+.in +.3i >+The screen number fvwm is running on. Useful for setups with >+multiple screens. >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[fg.cs<n>] >+.in -.5i >+.in +.5i >+$[bg.cs<n>] >+.in -.5i >+.in +.5i >+$[hilight.cs<n>] >+.in -.5i >+.in +.5i >+$[shadow.cs<n>] >+.in +.3i >+These class of parameters is replaced with the name of the >+foreground (fg), background (bg), hilight (hilight) or shadow >+(shadow) color that is defined in colorset <n> (replace <n> with >+zero or a positive integer). For example "$[fg.cs3]" is expanded >+to the name of the foreground color of colorset 3 (in >+rgb:rrrr/gggg/bbbb form). Please refer to the man page of the >+.B FvwmTheme >+module for details about colorsets. Note that although other >+parameters cannot be used in module configuration lines, it is >+possible to use this class of parameters. They can be used >+wherever a module expects a color name. Since the >+.B FvwmTheme >+module is not running when fvwm first passes through its >+configuration file, you may not get the desired results if you use >+this in commands like >+.EX >+Style * HilightFore $[fg.cs0], HilightBack $[bg.cs0] >+.EE >+.in -.3i >+.in -.5i >+ >+.in +.5i >+$[...] >+.in +.3i >+If the string within the braces is neither of the above, fvwm >+tries to find an environment variable with this name and replaces >+its value if one is found (e.g. "$[PAGER]" could be replaced by >+"more"). Otherwise the string is left as is. >+.in -.3i >+.in -.5i >+ >+Some examples can be found in the description of the >+.B AddToFunc >+command. >+ >+.SS THE LIST OF BUILTIN COMMANDS >+ >+The commands descriptions below are grouped together in the >+following sections. The sections are hopefully sorted in order of >+usefulness to the newcomer. >+.EX >+- Menu commands >+- Miscellaneous commands >+- Commands affecting window movement and placement >+- Commands for focus and mouse movement >+- Commands controlling window state >+- Commands for mouse, key and stroke bindings >+- The Style command (controlling window styles) >+- Other commands controlling window styles >+- Commands controlling the virtual desktop >+- Commands for user functions and shell commands >+- Conditional commands >+- Module commands >+- Quit, restart and session management commands >+- Color gradients >+.EE >+ >+.SS COMMANDS FOR MENUS >+ >+.TP >+.BI "AddToMenu " menu-name " [" menu-label " " action "]" >+ >+Begins or adds to a menu definition. Typically a menu definition >+looks like this: >+.EX >+AddToMenu Utilities Utilities Title >+ + Xterm Exec exec xterm -e tcsh >+ + Rxvt Exec exec rxvt >+ + "Remote Logins" Popup Remote-Logins >+ + Top Exec exec rxvt -T Top -n \\ >+ Top -e top >+ + Calculator Exec exec xcalc >+ + Xman Exec exec xman >+ + Xmag Exec exec xmag >+ + emacs Exec exec xemacs >+ + Mail MailFunction \\ >+ xmh "-font fixed" >+ + "" Nop >+ + Modules Popup Module-Popup >+ + "" Nop >+ + Exit Fvwm Popup Quit-Verify >+.EE >+The menu could be invoked via >+.EX >+Mouse 1 R A Menu Utilities Nop >+.EE >+or >+.EX >+Mouse 1 R A Popup Utilities >+.EE >+There is no end-of-menu symbol. Menus do not have to be defined >+in a contiguous region of the >+.I .fvwm2rc >+file. The quoted portion in the above examples is the menu label, >+which appears in the menu when the user pops it up. The remaining >+portion is a built-in command which should be executed if the user >+selects that menu item. An empty menu-label ("") and the >+.B Nop >+function can be used to insert a separator into the menu. >+ >+The keywords >+.IR DynamicPopUpAction " and " DynamicPopDownAction >+have a special meaning when used as the name of a menu item. The >+action following the keyword is executed whenever the menu is >+popped up or down. This way you can implement dynamic menus. It >+is even possible to destroy itself with >+.B DestroyMenu >+and the rebuild from scratch. When the menu has been destroyed >+(unless you used the >+.I recreate >+option when destroying the menu), do not forget to add the dynamic >+action again. >+ >+Note: Do not trigger actions that require user interaction. They >+will probably fail and may screw up your menus. See >+.B Silent >+command. >+ >+Warning: Do not issue >+.B MenuStyle >+commands as dynamic menu actions. Chances are good that this will >+crash fvwm. >+ >+Example (File browser): >+.EX >+# You can find the shell script >+# fvwm_make_browse_menu.sh in the utils >+# directory of the distribution. >+AddToMenu BrowseMenu >++ DynamicPopupAction Piperead \\ >+ 'fvwm_make_browse_menu.sh BrowseMenu' >+.EE >+Example (Picture menu): >+.EX >+# Build a menu of all .jpg files in >+# $HOME/Pictures >+AddToMenu JpgMenu foo title >++ DynamicPopupAction Function MakeJpgMenu >+ >+AddToFunc MakeJpgMenu >++ I DestroyMenu recreate JpgMenu >++ I AddToMenu JpgMenu Pictures Title >++ I PipeRead 'for i in $HOME/Pictures/*.jpg; \\ >+ do echo AddToMenu JpgMenu "`basename $i`" Exec xv $i; done' >+.EE >+The keyword >+.I MissingSubmenuFunction >+has a similar meaning. It is executed whenever you try to pop up >+a sub-menu that does not exist. With this function you can define >+and destroy menus on the fly. You can use any command after the >+keyword, but the name of a function defined with >+.B AddToFunc >+follows it, fvwm executes this command: >+.EX >+Function <function-name> <menu-name> >+.EE >+I.e. the name is passed to the function as its first argument and >+can be referred to with "$0". >+ >+Example: >+.EX >+# There is another shell script >+# fvwm_make_directory_menu.sh in the utils >+# directory of the distribution. To use it, >+# define this function in your configuration >+# file: >+ >+AddToFunc MakeMissingDirectoryMenu >++ I Exec fvwm_make_directory_menu.sh $0 >+ >+AddToMenu SomeMenu >++ MissingSubmenuFunction MakeMissingDirectoryMenu >++ "Root directory" Popup / >+.EE >+This is another implementation of the file browser that uses >+sub-menus for subdirectories. >+ >+Titles can be used within the menu. If you add the option >+.I top >+behind the keyword >+.BR Title , >+the title is added to the top of the menu. If there was a title >+already, it is overwritten. >+.EX >+AddToMenu Utilities Tools Title top >+.EE >+All text up to the first >+.SM Tab >+in the menu label is aligned to the left side of the menu, all >+text right of the first >+.SM Tab >+is aligned to the left in a second column and all text thereafter >+is placed right aligned in the third column. All other >+.SM Tabs >+are replaced by spaces. Note that you can change this format with >+the >+.I ItemFormat >+option of the >+.B MenuStyle >+command. >+ >+If the menu-label contains an ampersand ('&'), the next character >+is taken as a hot-key for the menu item. Hot-keys are underlined >+in the label. To get a literal '&', insert "&&". Pressing the >+hot-key moves through the list of menu items with this hot-key or >+selects an item that is the only one with this hot-key. >+ >+If the menu-label contains a sub-string which is set off by stars, >+then the text between the stars is expected to be the name of an >+xpm-icon or bitmap-file to insert in the menu. To get a literal >+'*', insert "**". For example >+.EX >+ + Calculator*xcalc.xpm* Exec exec xcalc >+.EE >+inserts a menu item labeled "Calculator" with a picture of a >+calculator above it. The following: >+.EX >+ + *xcalc.xpm* Exec exec xcalc >+.EE >+Omits the "Calculator" label, but leaves the picture. >+ >+If the menu-label contains a sub-string which is set off by >+percent signs, then the text between the percent signs is expected >+to be the name of an xpm-icon or bitmap-file (a so called mini >+icon to insert to the left of the menu label. A second mini icon >+that is drawn at the right side of the menu can be given in the >+same way. To get a literal '%', insert "%%". For example >+.EX >+ + Calculator%xcalc.xpm% Exec exec xcalc >+.EE >+inserts a menu item labeled "Calculator" with a picture of a >+calculator to the left. The following: >+.EX >+ + %xcalc.xpm% Exec exec xcalc >+.EE >+Omits the "Calculator" label, but leaves the picture. The >+pictures used with this feature should be small (perhaps 16x16). >+If the menu-name (not the label) contains a sub-string which is >+set off by at signs ('@'), then the text between them is expected >+to be the name of an xpm or bitmap file to draw along the left >+side of the menu (a side pixmap). You may want to use the >+.I SidePic >+option of the >+.B MenuStyle >+command instead. To get a literal '@', insert "@@". For example >+.EX >+AddToMenu StartMenu@linux-menu.xpm@ >+.EE >+creates a menu with a picture in its bottom left corner. >+ >+If the menu-name also contains a sub-string surrounded by '^'s, then >+the text between '^'s is expected to be the name of an X11 color >+and the column containing the side picture is colored with that >+color. You can set this color for a menu style using the >+.I SideColor >+option of the >+.B MenuStyle >+command. To get a literal '^', insert "^^". Example: >+.EX >+AddToMenu StartMenu@linux-menu.xpm@^blue^ >+.EE >+creates a menu with a picture in its bottom left corner and >+colors with blue the region of the menu containing the picture. >+ >+In all the above cases, the name of the resulting menu is name >+specified, stripped of the substrings between the various >+delimiters. >+ >+.TP >+.BI "ChangeMenuStyle " "menustyle menu ..." >+Changes the menu style of >+.IR menu " to " menustyle . >+You may specified more than one menu in each call of >+.BR ChangeMenuStyle . >+.EX >+ChangeMenuStyle pixmap1 \\ >+ ScreenSaverMenu ScreenLockMenu >+.EE >+ >+.TP >+.BI "CopyMenuStyle " "orig-menustyle dest-menustyle" >+Copy >+.IR orig-menustyle " to " dest-menustyle , >+where >+.IR orig-menustyle >+is an existing menu style. If the menu style >+.IR dest_menustyle >+does not exist, then it is created. >+ >+.TP >+.BI "DestroyMenu [" recreate "] " menu >+Deletes a menu, so that subsequent references to it are no longer >+valid. You can use this to change the contents of a menu during >+an fvwm session. The menu can be rebuilt using >+.BR AddToMenu . >+The optional parameter >+.I recreate >+tells fvwm not to throw away the menu completely but to throw away >+all the menu items (including the title). >+.EX >+DestroyMenu Utilities >+.EE >+ >+.TP >+.BI "DestroyMenuStyle " menustyle >+Deletes the menu style named >+.I menustyle >+and changes all menus using this style to the default style, you >+cannot destroy the default menu style. >+.EX >+DestroyMenuStyle pixamp1 >+.EE >+ >+.IP "\fBMenu\fP \fImenu-name\fP \ >+\fB[\fP \fIposition\fP \ >+\fB] [\fP \fIdouble-click-action\fP \ >+\fB]\fP" >+Causes a previously defined menu to be popped up in a sticky >+manner. That is, if the user invokes the menu with a click action >+instead of a drag action, the menu stays up. The command >+.I double-click-action >+is invoked if the user double-clicks a button (or hits the key >+rapidly twice if the menu is bound to a key) when bringing up the >+menu. If the double click action is not specified, double >+clicking on the menu does nothing. However, if the menu begins >+with a menu item (i.e. not with a title or a separator) and the >+double click action is not given, double clicking invokes the >+first item of the menu (but only if the pointer really was over >+the item). >+ >+Several other commands affect menu operation. See >+.BR MenuStyle " and " SetAnimation . >+When in a menu, keyboard shortcuts work as expected. Cursor >+keystrokes are also allowed. Specifically, >+.SM Tab, >+.SM Meta-Tab, >+.SM Cursor-Down, >+.SM Ctrl-N, >+or >+.SM Ctrl-J >+move to the next item; >+.SM Shift-Tab, >+.SM Shift-Meta-Tab, >+.SM Cursor-Up, >+.SM Ctrl-P, >+or >+.SM Ctrl-K >+move to the prior item; >+.SM Cursor-Left >+or >+.SM Ctrl-B >+returns to the prior menu; >+.SM Cursor-Right >+or >+.SM Ctrl-F >+pop up the next menu; >+.SM Ctrl-Cursor-Up, >+.SM Shift-Ctrl-Meta-Tab >+and >+.SM Page-Up >+move up five items; >+.SM Ctrl-Cursor-Down, >+.SM Ctrl-Meta-Tab >+and >+.SM Page-Down >+move down five items, respectively; >+.SM Home, >+.SM Shift-Cursor-Up >+or >+.SM End, >+.SM Shift-Cursor-Down >+move to the first or last item, respectively; >+.SM Meta-Cursor-Up >+or >+.SM Meta-Cursor-Down >+move just behind the next or previous separator; >+.SM Shift-Ctrl-Tab >+or >+.SM Ctrl-Tab >+work exactly the same; >+.SM Enter, >+.SM Return, >+or >+.SM Space >+executes the current item; >+.SM Insert >+opens the "More..." sub-menu if any; >+.SM Escape >+and >+.SM Delete >+exit the current sequence of menus. >+ >+The pointer is warped to where it was when the menu was invoked if >+it was both invoked and terminated with a keystroke. >+ >+The >+.I position >+arguments allow placement of the menu somewhere on the screen, for >+example centered on the visible screen or above a title bar. >+Basically it works like this: you specify a >+.I context-rectangle >+and an offset to this rectangle by which the upper left corner of >+the menu is moved from the upper left corner of the rectangle. >+The >+.I position >+arguments consist of several parts: >+.EX >+.BI "[" context-rectangle "] " "x y" " [" special-options "]" >+.EE >+The >+.I context-rectangle >+can be one of: >+ >+.in +.5i >+.BR Root >+.in +.3i >+the root window of the current screen. >+.in -.3i >+.BR XineramaRoot >+.in +.3i >+the root window of the whole Xinerama screen. Equivalent to >+"root" when Xinerama is not used. >+.in -.3i >+.BR Mouse >+.in +.3i >+a 1x1 rectangle at the mouse position. >+.in -.3i >+.BR Window >+.in +.3i >+the window with the focus. >+.in -.3i >+.BR Interior >+.in +.3i >+the inside of the focused window. >+.in -.3i >+.BR Title >+.in +.3i >+the title of the focused window or icon. >+.in -.3i >+.BR Button<n> >+.in +.3i >+button #n of the focused window. >+.in -.3i >+.BR Icon >+.in +.3i >+the focused icon. >+.in -.3i >+.BR Menu >+.in +.3i >+the current menu. >+.in -.3i >+.BR Item >+.in +.3i >+the current menu item. >+.in -.3i >+.BR Context >+.in +.3i >+the current window, menu or icon. >+.in -.3i >+.BR This >+.in +.3i >+whatever widget the pointer is on (e.g. a corner of a window or >+the root window). >+.in -.3i >+.BI "Rectangle <" geometry ">" >+.in +.3i >+the rectangle defined by >+.RI < geometry > >+in X geometry format. Width and height default to 1 if omitted. >+.in -.3i >+.in -.5i >+ >+If the context-rectangle is omitted or illegal (e.g. "item" on a >+window), "Mouse" is the default. Note that not all of these make >+sense under all circumstances (e.g. "Icon" if the pointer is on a >+menu). >+ >+The offset values >+.I x >+and >+.I y >+specify how far the menu is moved from it's default position. By >+default, the numeric value given is interpreted as a percentage of >+the context rectangle's width (height), but with a trailing >+.RI ' m ' >+the menu's width (height) is used instead. Furthermore a trailing >+.RI ' p ' >+changes the interpretation to mean pixels. >+ >+Instead of a single value you can use a list of values. All >+additional numbers after the first one are separated from their >+predecessor by their sign. Do not use any other separators. >+ >+If >+.IR x " or " y >+are prefixed with "o<number>" where <number> is an integer, the >+menu and the rectangle are moved to overlap at the specified >+position before any other offsets are applied. The menu and the >+rectangle are placed so that the pixel at <number> percent of the >+rectangle's width/height is right over the pixel at <number> >+percent of the menu's width/height. So "o0" means that the >+top/left borders of the menu and the rectangle overlap, with >+"o100" it's the bottom/right borders and if you use "o50" they are >+centered upon each other (try it and you will see it is much >+simpler than this description). The default is "o0". The prefix >+"o<number>" is an abbreviation for "+<number>-<number>m". >+ >+A prefix of >+.RI ' c ' >+is equivalent to "o50". Examples: >+.EX >+# window list in the middle of the screen >+WindowList Root c c >+ >+# menu to the left of a window >+Menu name window -100m c+0 >+ >+# popup menu 8 pixels above the mouse pointer >+Popup name mouse c -100m-8p >+ >+# somewhere on the screen >+Menu name rectangle 512x384+1+1 +0 +0 >+ >+# centered vertically around a menu item >+AddToMenu foobar-menu >+ + "first item" Nop >+ + "special item" Popup "another menu" item \\ >+ +100 c >+ + "last item" Nop >+ >+# above the first menu item >+AddToMenu foobar-menu >+ + "first item" Popup "another menu" item \\ >+ +0 -100m >+.EE >+Note that you can put a sub-menu far off the current menu so you >+could not reach it with the mouse without leaving the menu. If >+the pointer leaves the current menu in the general direction of >+the sub-menu the menu stays up. >+ >+The >+.IR special-options : >+ >+.in +.5i >+The >+.IR animated " and " Mwm " or " Win >+menu styles may move a menu somewhere else on the screen. If you >+do not want this you can add >+.I Fixed >+as an option. This might happen for example if you want the menu >+always in the top right corner of the screen. >+ >+Where do you want a sub-menu to appear when you click on it's menu >+item? The default is to place the title under the cursor, but if >+you want it where the position arguments say, use the >+.I SelectInPlace >+option. If you want the pointer on the title of the menu, use >+.I SelectWarp >+too. Note that these options apply only if the >+.IB "PopupAsRootMenu " MenuStyle >+option is used. >+ >+The pointer is warped to the title of a sub-menu whenever the >+pointer would be on an item when the sub-menu is popped up >+.RI ( fvwm >+menu style) or never warped to the title at all >+.RI ( Mwm " or " Win >+menu styles). You can force (forbid) warping whenever the sub-menu >+is opened with the >+.IR WarpTitle " (" NoWarp ") option." >+ >+Note that the >+.I special-options >+do work with a normal menu that has no other position arguments. >+.in -.5i >+ >+.TP >+.BI "MenuStyle " "stylename options" >+Sets a new menu style or changes a previously defined style. The >+.I stylename >+is the style name; if it contains spaces or tabs it has to be >+quoted. The name "*" is reserved for the default menu style. The >+default menu style is used for every menu-like object (e.g. the >+window created by the >+.B WindowList >+command) that had not be assigned a style using the >+.BR ChangeMenuStyle . >+See also >+.BR DestroyMenuStyle . >+When using monochrome color options are ignored. >+ >+.I options >+is a comma separated list containing some of the keywords >+Fvwm / Mwm / Win, >+BorderWidth, >+Foreground, >+Background, >+Greyed, >+HilightBack / HilightBackOff, >+ActiveFore / ActiveForeOff, >+MenuColorset, >+ActiveColorset, >+GreyedColorset, >+Hilight3DThick / Hilight3DThin / Hilight3DOff, >+Hilight3DThickness, >+Animation / AnimationOff, >+Font, >+MenuFace, >+PopupDelay, >+PopupOffset, >+TitleWarp / TitleWarpOff, >+TitleUnderlines0 / TitleUnderlines1 / TitleUnderlines2, >+SeparatorsLong / SeparatorsShort, >+TrianglesSolid / TrianglesRelief, >+PopupImmediately / PopupDelayed, >+PopdownImmediately / PopdownDelayed, >+DoubleClickTime, >+SidePic, >+SideColor, >+PopupAsRootMenu / PopupAsSubmenu, >+RemoveSubmenus / HoldSubmenus, >+SubmenusRight / SubmenusLeft, >+SelectOnRelease, >+ItemFormat, >+VerticalItemSpacing, >+VerticalTitleSpacing, >+AutomaticHotkeys / AutomaticHotkeysOff. >+ >+In the above list some options are listed as option pairs or >+triples with a '/' in between. These options exclude each other. >+ >+.IR Fvwm ", " Mwm ", " Win >+reset all options to the style with the same name in former >+versions of fvwm. The default for new menu styles is >+.I Fvwm >+style. These options override all others except >+.IR Foreground ", " Background ", " Greyed ", " HilightBack ", " >+.IR HilightFore " and " PopupDelay , >+so they should be used only as the first option specified for a >+menu style or to reset the style to defined behavior. The same >+effect can be created by setting all the other options one by one. >+ >+.IR Mwm " and " Win >+style menus popup sub-menus automatically. >+.I Win >+menus indicate the current menu item by changing the background to dark. >+.I Fvwm >+sub-menus overlap the parent menu, >+.IR Mwm " and " Win >+style menus never overlap the parent menu. >+ >+.I Fvwm >+style is equivalent to HilightBackOff, Hilight3DThin, >+ActiveForeOff, AnimationOff, Font, MenuFace, PopupOffset 0 67, >+TitleWarp, TitleUnderlines1, SeparatorsShort, TrianglesRelief, >+PopupDelayed, PopdownDelayed, PopupAsSubmenu, HoldSubmenus, >+SubmenusRight, BorderWidth 2, AutomaticHotkeysOff. >+ >+.I Mwm >+style is equivalent to HilightBackOff, Hilight3DThick, >+ActiveForeOff, AnimationOff, Font, MenuFace, PopupOffset -3 100, >+TitleWarpOff, TitleUnderlines2, SeparatorsLong, TrianglesRelief, >+PopupImmediately, PopdownDelayed, PopupAsSubmenu, HoldSubmenus, >+SubmenusRight, BorderWidth 2, AutomaticHotkeysOff. >+ >+.I Win >+style is equivalent to HilightBack, Hilight3DOff, ActiveForeOff, >+AnimationOff, Font, MenuFace, PopupOffset -5 100, TitleWarpOff, >+TitleUnderlines1, SeparatorsShort, TrianglesSolid, >+PopupImmediately, PopdownDelayed, PopupAsSubmenu, RemoveSubmenus, >+SubmenusRight, BorderWidth 2, AutomaticHotkeysOff. >+ >+.I BorderWidth >+takes the thickness of the border around the menus in pixels. It >+may be zero to 50 pixels. The default is 2. Using an illegal >+value reverts the border width to the default. >+ >+.IR Foreground " and " Background >+may have a color name as an argument. This color is used for menu >+text or the menu's background. You can omit the color name to >+reset these colors to the built in default. >+ >+.I Greyed >+may have a color name as an argument. This color is the one used >+to draw a menu-selection which is prohibited (or not recommended) >+by the Mwm hints which an application has specified. If the color >+is omitted the color of greyed menu entries is based on the >+background color of the menu. >+ >+.IR HilightBack " and " HilightBackOff >+switch hilighting the background of the selected menu item on and >+off. A specific background color may be used by providing the >+color name as an argument to >+.IR HilightBack . >+If you use this option without an argument the color is based on >+the menu's background color. >+ >+.I ActiveFore " and " ActiveForeOff >+switch hilighting the foreground of the selected menu item on and >+off. A specific foreground color may be used by providing the >+color name as an argument to >+.IR ActiveFore . >+Omitting the color name has the same effect as using >+.IR ActiveForeOff . >+ >+.I MenuColorset >+controls if a colorset is used instead of the >+.IR Foreground ", " Background " and " MenuFace >+menu styles. If the >+.I MenuColorset >+keyword is followed by a number equal to zero or greater, this >+number is taken as the number of the colorset to use. If the >+number is omitted, the colorset is switched off and the regular >+menu styles are used again. The foreground and background colors >+of the menu items are replaced by the colors from the colorset. >+If the colorset has a pixmap defined, this pixmap is used as the >+background of the menu. Note that the >+.I MenuFace >+menu style has been optimized for memory consumption and may use >+less memory than the background from a colorset. The shape mask >+from the colorset is used to shape the menu. Please refer to the >+description of the >+.B Colorset >+command and the documentation of the >+.B FvwmTheme >+module for details about colorsets. >+ >+.I ActiveColorset >+works exactly like >+.IR MenuColorset , >+but the foreground from the colorset replaces the color given with >+the >+.I ActiveFore >+menu style and the colorset's background color replaces the color >+given with the >+.I HilightBack >+command (to turn on background hilighting you have to use the >+.I HilightBack >+menu style too). If specified, the hilight and shadow colors >+from the colorset are used too. The pixmap and shape mask from >+the colorset are not used. >+ >+.I GreyedColorset >+works exactly like >+.IR MenuColorset , >+but the foreground from the colorset replaces the color given with >+the >+.I Greyed >+menu style. No other parts of the colorset are used. >+ >+.IR Hilight3DThick ", " Hilight3DThin " and " Hilight3DOff >+determine if the selected menu item is hilighted with a 3D >+relief. Thick reliefs are two pixels wide, thin reliefs are one >+pixel wide. >+ >+.I Hilight3DThickness >+takes one numeric argument that may be between -50 and +50 >+pixels. With negative values the menu item gets a pressed in look. >+The above three commands are equivalent to a thickness of 2, 1 and >+0. >+ >+.IR Animation " and " AnimationOff >+turn menu animation on or off. When animation is on, sub-menus >+that don't fit on the screen cause the parent menu to be shifted >+to the left so the sub-menu can be seen. >+ >+.I Font >+takes a font name as an argument. If a font by this name exists >+it is used for the text of all menu items. If it does not exist >+or if the name is left blank the built in default is used. >+ >+.I MenuFace >+enforces a fancy background upon the menus. You can use the same >+options for >+.I MenuFace >+as for the >+.BR ButtonStyle . >+See description of >+.B ButtonStyle >+command and the >+.B COLOR GRADIENTS >+sections for more information. If you use >+.I MenuFace >+without arguments the style is reverted back to normal. >+ >+Some examples of MenuFaces are: >+.EX >+MenuFace DGradient 128 2 lightgrey 50 blue 50 \\ >+ white >+MenuFace TiledPixmap texture10.xpm >+MenuFace HGradient 128 2 Red 40 Maroon 60 \\ >+ White >+MenuFace Solid Maroon >+.EE >+Note: The gradient styles H, V, B and D are optimized for high >+speed and low memory consumption in menus. This is not the case >+for all the other gradient styles. They may be slow and consume >+huge amounts of memory, so if you encounter performance problems >+with them you may be better off by not using them. To improve >+performance you can try one or all of the following: >+ >+Turn hilighting of the active menu item other than foreground >+color off: >+.EX >+MenuStyle <style> Hilight3DOff, HilightBackOff >+MenuStyle <style> ActiveFore <preferred color> >+.EE >+Make sure sub-menus do not overlap the parent menu. This can >+prevent menus being redrawn every time a sub-menu pops up or down. >+.EX >+MenuStyle <style> PopupOffset 1 100 >+.EE >+Run you X server with backing storage. If your X Server is >+started with the -bs option, turn it off. If not try the -wm >+option. >+.EX >+startx -- -wm >+.EE >+You may have to adapt this example to your system (e.g. if you use >+xinit to start X). >+ >+.I PopupDelay >+requires one numeric argument. This value is the delay in >+milliseconds before a sub-menu is popped up when the pointer moves >+over a menu item that has a sub-menu. If the value is zero no >+automatic pop up is done. If the argument is omitted the built in >+default is used. Note that the popup delay has no effect if the >+.I PopupImmediately >+option is used since sub-menus pop up immediately then. >+ >+.I PopupImmediately >+makes menu items with sub-menus pop up it up as soon as the >+pointer enters the item. The >+.I PopupDelay option >+is ignored then. If >+.I PopupDelayed >+is used fvwm looks at the >+.I PopupDelay >+option if or when this automatic popup happens. >+ >+.I PopdownDelay >+works exactly like >+.I PopupDelay >+but determines the timeout of the >+.I PopupDelayed >+style. >+ >+.I PopdownImmediately >+makes sub-menus vanish as soon as the pointer leaves the sub-menu >+and the correspondent item in the parent menu. With the opposite >+option >+.I PopdownDelayed >+the sub-menu only pops down after the time specified with the >+.I PopdownDelay >+option. This comes handy when the pointer often strays off the >+menu item when trying to move into the sub-menu. Whenever there >+is a conflict between the >+.IR PopupImmediately ", " PopupDelayed ", " PopupDelay >+styles and the >+.IR PopdownImmediately ", " PopdownDelayed ", " PopdownDelay >+styles, the >+.I Popup... >+styles win when using mouse navigation and the >+.I Popdown... >+styles win when navigating with the keyboard. >+ >+.I PopupOffset >+requires two integer arguments. Both values affect where >+sub-menus are placed relative to the parent menu. If both values >+are zero, the left edge of the sub-menu overlaps the left edge of >+the parent menu. If the first value is non-zero the sub-menu is >+shifted that many pixels to the right (or left if negative). If >+the second value is non-zero the menu is moved by that many >+percent of the parent menu's width to the right or left. >+ >+.IR TitleWarp " and " TitleWarpOff >+affect if the pointer warps to the menu title when a sub-menu is >+opened or not. Note that regardless of this setting the pointer is >+not warped if the menu does not pop up under the pointer. >+ >+.IR TitleUnderlines0 ", " TitleUnderlines1 " and " TitleUnderlines2 >+specify how many lines are drawn below a menu title. >+ >+.IR SeparatorsLong " and " SeparatorsShort >+set the length of menu separators. Long separators run from the >+left edge all the way to the right edge. Short separators leave a >+few pixels to the edges of the menu. >+ >+.IR TrianglesSolid " and " TrianglesRelief >+affect how the small triangles for sub-menus is drawn. Solid >+triangles are filled with a color while relief triangles are >+hollow. >+ >+.I DoubleClickTime >+requires one numeric argument. This value is the time in >+milliseconds between two mouse clicks in a menu to be considered >+as a double click. The default is 450 milliseconds. If the >+argument is omitted the double click time is reset to this >+default. >+ >+.I SidePic >+takes the name of an xpm or bitmap file as an argument. The >+picture is drawn along the left side of the menu. The >+.I SidePic >+option can be overridden by a menu specific side pixmap (see >+.BR AddToMenu ). >+If the file name is omitted an existing side pixmap is remove from >+the menu style. >+ >+.I SideColor >+takes the name of an X11 color as an argument. This color is used >+to color the column containing the side picture (see >+above). The SideColor option can be overridden by a menu specific >+side color (see >+.BR AddToMenu ). >+If the color name is omitted the side color option is switched off. >+ >+.IR PopupAsRootMenu " and " PopupAsSubmenu >+change the behavior when you click on a menu item that opens a >+sub-menu. With >+.I PopupAsRootMenu >+the original menu is closed before the sub-menu appears, with >+.I PopupAsSubmenu >+it is not, so you can navigate back into the >+parent menu. Furthermore, with >+.I PopupAsSubmenu >+the sub-menu is held open (posted) regardless of where you move >+the mouse. Depending on your menu style this may simplify >+navigating through the menu. Any keystroke while a menu is posted >+reverts the menu back to the normal behavior. >+.I PopupAsSubmenu >+is the default. >+ >+.I RemoveSubmenus >+instructs fvwm to remove sub-menus when you move back into the >+parent menu. With >+.I HoldSubmenus >+the sub-menu remains visible. You probably want to use >+.I HoldSubmenus >+if you are using the >+.I PopupDelayed >+style. >+.I RemoveSubmenus >+affects menu navigation with the keyboard. >+ >+.I SelectOnRelease >+takes an optional key name as an argument. If the given key is >+release in a menu using this style, the current menu item is >+selected. This is intended for >+.SM Alt-Tab >+.B WindowList >+navigation. The key name is a standard X11 key name as defined in >+.IR /usr/include/X11/keysymdef.h , >+with the leading "XK_" omitted. To disable this behaviour, omit >+the key name. >+ >+Note: Some X servers do not support KeyRelease events. >+.I SelectOnRelease >+does not work on such a machine. >+ >+.I ItemFormat >+takes a special string as its argument that determines the layout >+of the menu items. Think of the format string as if it were a >+menu item. All you have to do is tell fvwm where to place the >+different parts of the menu item (i.e. the labels, the triangle >+denoting a sub menu, the mini icons and the side pic) in the blank >+area. The string consists of spaces, >+.SM Tab >+characters and formatting directives beginning with '%'. Any >+illegal characters and formatting directives are silently ignored: >+ >+.in +.5i >+.BR %l ", " %c " and " %r >+.in +.3i >+Insert the next item label. Up to three labels can be used. The >+item column is left-aligned >+.RB ( %l ), >+centered >+.RB ( %c ) >+or right-aligned >+.RB ( %r ). >+.in -.3i >+.B %i >+.in +.3i >+Inserts the mini icon. >+.in -.3i >+.BR %> " and " %< >+.in +.3i >+Insert the sub-menu triangle pointing either to the right >+.RB ( %> ) >+or to the left >+.RB ( %< ) >+.in -.3i >+.B %| >+.in +.3i >+The first >+.B %| >+denotes the beginning of the area that is highlighted either with >+a background color or a relief (or both). The second >+.B %| >+marks the end of this area. >+.B %| >+can be used up to twice in the string. If you don't add one or >+both of them, fvwm sets the margins to the margins of the whole >+item (not counting the side picture). >+.in -.3i >+.B %s >+.in +.3i >+Places the side picture either at the beginning or the end of the >+menu. This directive may be used only once and only as the first >+or last in the format string. If the >+.B %s >+is not at the beginning of the string, all characters to the right >+of it are silently ignored. >+.in -.3i >+.BR Space ", " Tab ", " %Space " and " %Tab >+.in +.3i >+Add a gap as large as one respectively eight spaces are with the >+font used in the menu items. The whole string must be quoted if >+spaces or tabs are used. >+.in -.3i >+.B %p >+.in +.3i >+Like >+.SM Space >+and >+.SM Tab >+.B %p >+inserts an empty area into the item, but with better control of >+its size (see below). >+.in -.3i >+.in -.5i >+ >+You can define an additional space before and after each of the >+objects like this: >+.EX >+.BI % left . right p >+.EE >+This means: if the object is defined in the menu (e.g. if it is >+.B %s >+and you use a side picture, or it is >+.B %l >+for the third column and there are items defined that actually >+have a third column), then add >+.I left >+pixels before the object and >+.I right >+pixels after it. You may leave out the >+.I left >+or the >+.I .right >+parts if you don't need them. All values up to the screen width >+are allowed. Even negative values can be used with care. The >+.B p >+may be replaced with any other formatting directives described >+above. >+ >+Note: Only items defined in the format string are visible in the >+menus. So if you do not put a >+.B %s >+in there you do not see a side picture, even if one is specified. >+ >+Note: The >+.I SubmenusLeft >+style changes the default >+.I ItemFormat >+string, but if it was set manually it is not modified. >+ >+Note: If any unformatted title of the menu is wider than the >+widest menu item, the spaces between the different parts of the >+menu items are enlarged to match the width of the title. Leading >+left aligned objects in the format string >+.RB ( %l ", " %i ", "%< ", first " %| ) >+stick to the left edge of the menu and trailing right aligned >+objects >+.RB ( %r ", " %i ", "%> ", second " %| ) >+stick to the right edge. The gaps between the remaining items are >+enlarged equally. >+ >+Examples: >+.EX >+MenuStyle * ItemFormat \\ >+ "%.4s%.1|%.5i%.5l%.5l%.5r%.5i%2.3>%1|" >+.EE >+Is the default string used by fvwm: (side picture + 4 pixels gap) >+(beginning of the hilighted area + 1 pixel gap) (mini icon + 5p) >+(first column left aligned + 5p) (second column left aligned + 5p) >+(third column right aligned + 5p) (second mini icon + 5p) (2p + >+sub-menu triangle + 3p) (1p + end of hilighted area). >+.EX >+MenuStyle * ItemFormat \\ >+ "%.1|%3.2<%5i%5l%5l%5r%5i%1|%4s" >+.EE >+Is used by fvwm with the >+.I SubmenusLeft >+option below. >+ >+.IR VerticalItemSpacing " and " VerticalTitleSpacing >+control the vertical spacing of menu items and titles like >+.I ItemFormat >+controls the horizontal spacing. Both take two numeric arguments >+that may range from -100 to +100. The first is the gap in pixels >+above a normal menu item (or a menu title), the second is the gap >+in pixels below it. Negative numbers do not make much sense and >+may screw up the menu completely. If no arguments are given or >+the given arguments are invalid, the built in defaults are used: >+one pixel above the item or title and two below. >+ >+.I SubmenusLeft >+mirrors the menu layout and behavior. Sub-menus pop up to the >+left, the sub-menu triangle is drawn left and the mini icon and >+side picture are drawn at the right side of the menu. The default >+is >+.IR SubmenusRight . >+The position hints of a menu are also affected by this setting, >+i.e. position hints using >+.IR item " or " menu >+as context rectangle and position hints using >+.I m >+offsets. >+ >+.IR AutomaticHotkeys " and " AutomaticHotkeysOff >+control the menu's ability to automatically provide hot-keys on >+the first character of each menu item's label. This behavior is >+always overridden if an explicit hot-key is assigned in the >+.B AddToMenu >+command. >+ >+Examples: >+.EX >+MenuStyle * Mwm >+MenuStyle * Foreground Black, Background gray40 >+MenuStyle * Greyed gray70, ActiveFore White >+MenuStyle * HilightBackOff, Hilight3DOff >+MenuStyle * Font lucidasanstypewriter-14 >+MenuStyle * MenuFace DGradient 64 darkgray \\ >+ MidnightBlue >+ >+MenuStyle red Mwm >+MenuStyle red Foreground Yellow >+MenuStyle red Background Maroon >+MenuStyle red Greyed Red, ActiveFore Red >+MenuStyle red HilightBackOff, Hilight3DOff >+MenuStyle red Font lucidasanstypewriter-12 >+MenuStyle red MenuFace DGradient 64 Red Black >+.EE >+Note that all style options could be placed on a single line for >+each style name. >+ >+.TP >+.BI "MenuStyle " "forecolor backcolor shadecolor font style" " [" anim "]" >+This is the old syntax of the >+.B MenuStyle >+command. It is obsolete and may be removed in the future. Please >+use the new syntax as described above. >+ >+Sets the menu style. When using monochrome the colors are >+ignored. The >+.I shadecolor >+is the one used to draw a menu-selection which is prohibited (or >+not recommended) by the Mwm hints which an application has >+specified. The style option is either >+.IR Fvwm ", " Mwm " or " Win , >+which changes the appearance and operation of the menus. >+ >+.IR Mwm " and " Win >+style menus popup sub-menus automatically. >+.I win >+menus indicate the current menu item by changing the background to >+black. >+.I fvwm >+sub-menus overlap the parent menu, >+.IR Mwm " and " win >+style menus never overlap the parent menu. >+ >+When the >+.I anim >+option is given, sub-menus that don't fit on the screen cause the >+parent menu to be shifted to the left so the sub-menu can be >+seen. See also >+.B SetAnimation >+command. >+ >+.TP >+.BI "Popup " PopupName " [" position "] [" default-action "]" >+This built-in has two purposes: to bind a menu to a key or mouse >+button, and to bind a sub-menu into a menu. The formats for the >+two purposes differ slightly. The >+.I position >+arguments are the same as for >+.BR Menu . >+The command >+.I default-action >+is invoked if the user clicks a button to invoke the menu and >+releases it immediately again (or hits the key rapidly twice if >+the menu is bound to a key). If the default action is not >+specified, double clicking on the menu does nothing. However, if >+the menu begins with a menu item (i.e. not with a title or a >+separator) and the default action is not given, double clicking >+invokes the first item of the menu (but only if the pointer really >+was over the item). >+ >+To bind a previously defined pop-up menu to a key or mouse button: >+.sp >+.in +.25i >+The following example binds mouse buttons 2 and 3 to a pop-up >+called "Window Ops". The menu pops up if the buttons 2 or 3 are >+pressed in the window frame, side-bar, or title-bar, with no >+modifiers (none of shift, control, or meta). >+.EX >+Mouse 2 FST N Popup "Window Ops" >+Mouse 3 FST N Popup "Window Ops" >+.EE >+Pop-ups can be bound to keys through the use of the >+.B Key >+built-in. Pop-ups can be operated without using the mouse by >+binding to keys and operating via the up arrow, down arrow, and >+enter keys. >+.in -.25i >+.sp >+To bind a previously defined pop-up menu to another menu, for use >+as a sub-menu: >+.sp >+.in +.25i >+The following example defines a sub-menu "Quit-Verify" and binds >+it into a main menu, called "RootMenu": >+.EX >+AddToMenu Quit-Verify >+ + "Really Quit Fvwm?" Title >+ + "Yes, Really Quit" Quit >+ + "Restart Fvwm" Restart >+ + "Restart Fvwm 1.xx" Restart fvwm1 -s >+ + "" Nop >+ + "No, Don't Quit" Nop >+ >+AddToMenu RootMenu "Root Menu" Title >+ + "Open XTerm Window" Popup NewWindowMenu >+ + "Login as Root" Exec exec xterm \\ >+ -fg green -T Root \\ >+ -n Root -e su - >+ + "Login as Anyone" Popup AnyoneMenu >+ + "Remote Hosts" Popup HostMenu >+ + "" Nop >+ + "X utilities" Popup Xutils >+ + "" Nop >+ + "Fvwm Modules" Popup Module-Popup >+ + "Fvwm Window Ops" Popup Window-Ops >+ + "" Nop >+ + "Previous Focus" Prev (AcceptsFocus) Focus >+ + "Next Focus" Next (AcceptsFocus) Focus >+ + "" Nop >+ + "Refresh screen" Refresh >+ + "Recapture screen" Recapture >+ + "" Nop >+ + "Reset X defaults" Exec xrdb -load \\ >+ $HOME/.Xdefaults >+ + "" Nop >+ + "" Nop >+ + Quit Popup Quit-Verify >+.EE >+.in -.25i >+.sp >+.B Popup >+differs from >+.B Menu >+in that pop-ups do not stay up if the user simply clicks. These >+are popup-menus, which are a little hard on the wrist. >+.B Menu >+menus stay up on a click action. See the >+.B Menu >+command for an explanation of the interactive behavior of menus. A >+menu can be open up to ten times at once, so a menu may even use >+itself or any of its predecessors as a sub-menu. >+ >+.TP >+.BI "Title" >+Does nothing. This is used to insert a title line in a popup or >+menu. >+ >+.SS MISCELLANEOUS COMMANDS >+ >+.TP >+.BI "BugOpts [" option " [" bool "]], " ... >+This command controls several workarounds for bugs in third party >+programs. The individual options are separated by commas. The >+optional argument >+.I bool >+is a boolean argument and controls if the bug workaround is >+enabled or not. It can either be "True" or "False" to turn the >+option on or off, or "toggle" to switch is back and forth. If >+.I bool >+is omitted, the default setting is restored. >+ >+.I FlickeringMoveWorkaround >+disables ConfigureNotify events that are usually sent to >+an application while it is moved. If some windows flicker >+annoyingly while being moved, this option may help you. Note that >+if this problem occurs it is not an fvwm bug, it is a problem of the >+application. >+ >+.I MixedVisualWorkaround >+makes fvwm install the root colormap before it does some >+operations using the root window visuals. This is only useful >+when the >+.B -visual >+option is used to start fvwm and then only with some >+configurations of some servers (e.g. Exceed 6.0 with an 8 bit >+PseudoColor root and fvwm using a 24 bit TrueColor visual). >+ >+The >+.I ModalityIsEvil >+option controls whether Motif applications have the ability to have >+modal dialogs (dialogs that force you to close them first before >+you can do anything else). The default is to not allow >+applications to have modal dialogs. Use this option with care. >+Once this option is turned on, you have to restart fvwm to turn it >+off. >+ >+.I RaiseOverNativeWindows >+makes fvwm try to raise the windows it manages over native windows >+of the X servers host system. This is needed for some X servers >+running under Windows or Windows NT. Fvwm tries to detect if it >+is running under such an X server and initializes the flag >+accordingly. >+ >+.I RaiseOverUnmanaged >+makes fvwm try to raise the windows it manages over >+override_redirect windows. This is used to cope with ill-mannered >+applications that use long-lived windows of this sort, contrary to >+.SM ICCCM >+conventions. >+ >+.I FlickeringQtDialogsWorkaround >+suppresses flickering of the focused window in some modules when >+using KDE or Qt applications with application modal dialog >+windows. By default this option is turned on. This option may be >+visually disturbing for other applications using windows not >+managed by fvwm. Since these applications are rare it is most >+likely safe to leave this option at its default. >+ >+.TP >+.BI "BusyCursor [" "Option bool" "], " ... >+This command controls the cursor during the execution of certain >+commands. >+.I Option >+can be >+.IR DynamicMenu ", " ModuleSynchronous ", " Read ", " Wait ", " * . >+An option must be followed by a boolean argument >+.IR bool . >+You can use commas to separate individual options. If you set an >+option to "True", then when the corresponding command is run, fvwm >+displays the cursor of the >+.I WAIT >+context of the >+.B CursorStyle >+command. "False" forces to not display the cursor. The default is: >+.EX >+BusyCursor DynamicMenu False, \\ >+ ModuleSynchronous False, Read False, \\ >+ Recapture True, Wait False >+.EE >+The option >+.I * >+refers to all available options. >+ >+The >+.I Read >+option also controls the >+.B PipeRead >+command. >+ >+The >+.I DynamicMenu >+option affects the >+.I DynamicPopupAction >+and >+.I MissingSubmenuFunction >+options of the >+.B AddToMenu >+command. If this option is set to "False", then the busy cursor >+is not displayed during a dynamic menu command even if this >+command is a >+.BR Read " or " PipeRead >+command and the >+.I Read >+option is set to "True". >+ >+The >+.I Wait >+option affects only the root cursor. During a wait pause the root >+cursor is replaced by the busy cursor and fvwm is still fully >+functional (you can escape from the pause, see the >+.B EscapeFunc >+command). If you want to use this option and if you do not use >+the default root cursor, you must set your root cursor with the >+.B CursorStyle >+command. >+ >+.TP >+.BI "ClickTime [" delay "]" >+Specifies the maximum delay in milliseconds between a button press >+and a button release for the >+.B Function >+built-in to consider the action a mouse click. The default delay >+is 150 milliseconds. Omitting the delay value resets the >+.B ClickTime >+to the default. >+ >+.TP >+.BI "ColorLimit " limit >+Specifies a >+.I limit >+on the colors used in pixmaps used by fvwm. Zero (the default) >+sets no limit. Fvwm uses pixmaps for icons, mini-icons, and >+pixmap borders, menu backgrounds and titles. This command limits >+pixmap colors to a set of colors that starts out with common >+colors. The current list contains about 60 colors and starts with >+white, black, grey, green, blue, red, cyan, yellow, and magenta. >+The command >+.EX >+ColorLimit 9 >+.EE >+would limit pixmaps to these 9 colors. >+ >+It makes the most sense to put this command at the front of the >+.I .fvwm2rc >+file. This command should occur before any menu definitions that >+contain mini-icons. >+ >+Solid frame and title colors (including shadows and gradients) are >+not controlled by this command. >+ >+This command only makes sense on screens that display a limited >+number of colors at once. If your display can display more than >+2 million colors at once, this command is ignored. Screens that >+only display 256 colors at once are known as 8 bit displays. The 2 >+million color cutoff point corresponds to 21 bit color, the most >+common screen that exceeds this limit would be 24 bit. >+ >+On 8 bit displays, the default color limit is set to the size of >+the built in table (about 60). We recommend that you start with >+the default value, and not include this command in your >+.IR .fvwm2rc . >+ >+.TP >+.BI "ColormapFocus " FollowsMouse | FollowsFocus >+By default, fvwm installs the colormap of the window that the >+cursor is in. If you use >+.EX >+ColormapFocus FollowsFocus >+.EE >+then the installed colormap is the one for the window that >+currently has the keyboard focus. >+ >+.IP "\fBCursorStyle\fP \fIcontext\fP \fB[\fP \fInumber\fP \ >+\fB|\fP \fIname\fP \ >+\fB|\fP \fIxpm\fP \ >+\fB|\fP \fINone\fP \ >+\fB|\fP \fITiny\fP \ >+\fB[\fP \fIfore back\fP \ >+\fB]]\fP" >+Defines a new cursor for the specified context. The various >+contexts are: >+ >+.in +.5i >+.BR "POSITION " (top_left_corner) >+.in +.3i >+used when initially placing windows >+.in -.3i >+ >+.BR "TITLE " (top_left_arrow) >+.in +.3i >+used in a window title-bar >+.in -.3i >+ >+.BR "DEFAULT " (top_left_arrow) >+.in +.3i >+used in windows that don't set their cursor >+.in -.3i >+ >+.BR "SYS " (hand2) >+.in +.3i >+used in one of the title-bar buttons >+.in -.3i >+ >+.BR "MOVE " (fleur) >+.in +.3i >+used when moving or resizing windows >+.in -.3i >+ >+.BR "RESIZE " (sizing) >+.in +.3i >+used when moving or resizing windows >+.in -.3i >+ >+.BR "WAIT " (watch) >+.in +.3i >+used during certain fvwm commands (see >+.B BusyCursor >+for details). >+.in -.3i >+ >+.BR "MENU " (top_left_arrow) >+.in +.3i >+used in menus >+.in -.3i >+ >+.BR "SELECT " (crosshair) >+.in +.3i >+used when the user is required to select a window >+.in -.3i >+ >+.BR "DESTROY " (pirate) >+.in +.3i >+used for DESTROY, CLOSE, and DELETE built-ins >+.in -.3i >+ >+.BR "TOP " (top_side) >+.in +.3i >+used in the top side-bar of a window >+.in -.3i >+ >+.BR "RIGHT " (right_side) >+.in +.3i >+used in the right side-bar of a window >+.in -.3i >+ >+.BR "BOTTOM " (bottom_side) >+.in +.3i >+used in the bottom side-bar of a window >+.in -.3i >+ >+.BR "LEFT " (left_side) >+.in +.3i >+used in the left side-bar of a window >+.in -.3i >+ >+.BR "TOP_LEFT " (top_left_corner) >+.in +.3i >+used in the top left corner of a window >+.in -.3i >+ >+.BR "TOP_RIGHT " (top_right_corner) >+.in +.3i >+used in the top right corner of a window >+.in -.3i >+ >+.BR "BOTTOM_LEFT " (bottom_left_corner) >+.in +.3i >+used in the bottom left corner of a window >+.in -.3i >+ >+.BR "BOTTOM_RIGHT " (bottom_right_corner) >+.in +.3i >+used in the bottom right corner of a window >+.in -.3i >+ >+.BR "TOP_EDGE " (top_side) >+.in +.3i >+used at the top edge of the screen. >+.in -.3i >+ >+.BR "RIGHT_EDGE " (right_side) >+.in +.3i >+used at the right edge of the screen. >+.in -.3i >+ >+.BR "BOTTOM_EDGE " (bottom_side) >+.in +.3i >+used at the bottom edge of the screen. >+.in -.3i >+ >+.BR "LEFT_EDGE " (left_side) >+.in +.3i >+used at the left edge of the screen. >+.in -.3i >+ >+.BR "ROOT " (left_ptr) >+.in +.3i >+used as the root cursor. >+.in -.3i >+ >+.BR "STROKE " (plus) >+.in +.3i >+used during a >+.B StrokeFunc >+command. >+.in -.3i >+.in -.5i >+ >+The defaults are shown in parentheses above. If you ever want to >+restore the default cursor for a specific context you can omit the >+second argument. >+ >+The second is either the numeric value of the cursor as defined in >+the include file >+.I X11/cursorfont.h >+or its name (without the XC_ prefix) or the name of an xpm file >+containing a pixmap of depth 1 with a mask and an optional >+hot-spot (if no hot-spot is defined, the hot-spot is placed in the >+center of the image). Furthermore the name can be >+.I None >+(no cursor) or >+.I Tiny >+(a single pixel as the cursor). For example: >+.EX >+# make the kill cursor be XC_gumby (both forms work): >+CursorStyle DESTROY 56 >+CursorStyle DESTROY gumby >+ >+CursorStyle TOP_LEFT topl.xpm >+CursorStyle ROOT hand1 yellow black >+.EE >+The optional >+.IR fg " and " bg >+arguments specify the foreground and background colors for the >+cursor, defaulting to black and white. >+ >+.TP >+.BI "DefaultColors [" "foreground background" "]" >+.B DefaultColors >+sets the default foreground and background colors used in >+miscellaneous windows created by fvwm, for example in the geometry >+feedback windows during a move or resize operation. If you don't >+want to change one color or the other, use - as its color name. >+To revert to the builtin default colors omit both color names. >+Note that the default colors are not used in menus, window titles >+or icon titles. >+ >+.TP >+.BI "DefaultColorset [" num "]" >+.B DefaultColorset >+sets the colorset used by the windows controlled by the >+.B DefaultColors >+command. To revert back to the >+.B DefaultColors >+colors use >+.EX >+DefaultColorset -1 >+.EE >+or any variant of the >+.B DefaultColors >+command. >+ >+.TP >+.BI "DefaultFont [" fontname "]" >+.B DefaultFont >+sets the default font to font >+.IR fontname . >+The default font is used by fvwm whenever no other font has been >+specified. To reset the default font to the built in default, >+omit the argument. The default font is used for menus, window >+titles, icon titles as well as the geometry feedback windows >+during a move or resize operation. To override the default font >+in a specific context, use the >+.BR "Style * Font" ", " "Style * IconFont" ", or " MenuStyle >+commands. >+ >+.TP >+.BI "DefaultIcon " filename >+sets the default icon which is used if a window has neither an >+client-supplied icon nor an icon supplied via the >+.I Icon >+option of the >+.B Style >+command. >+ >+.TP >+.BI "DefaultLayers " "bottom put top" >+changes the layers that are used for the >+.IR StaysOnBottom ", " StaysPut ", " StaysOnTop >+.B Style >+options. Initially, the layers 2, 4 and 6 are used. >+ >+.TP >+.BI "Emulate " Fvwm | Mwm | Win >+This command affects how miscellaneous things are done by >+fvwm. For example where the move/resize feedback window appears >+depends on this command. To have more Mwm- or Win-like behavior >+you can call >+.BI Emulate >+with >+.IR Mwm " or " Win >+as its argument. With >+.I Mwm >+resize and move feedback windows are in the center of the screen, >+instead of the upper left corner. >+ >+.TP >+.BI "EscapeFunc" >+By default the key sequence >+.SM Ctrl-Alt-Escape >+allows to escape from a >+.B Wait >+pause and from a locked >+.B ModuleSynchronous >+command. The >+.B EscapeFunc >+command used with the >+.B Key >+command allows to configure this key sequence. An example: >+.EX >+Key Escape A MC - >+Key Escape A S EscapeFunc >+.EE >+replaces the >+.SM Ctrl-Alt-Escape >+key sequence with >+.SM Shift-Escape >+for aborting a >+.B Wait >+pause and >+.B ModuleSynchronous >+command. >+.B EscapeFunc >+used outside the >+.B Key >+command does nothing. >+ >+.TP >+.BI "FakeClick [" "command value" "] ..." >+This command is mainly intended for debugging fvwm and no >+guarantees are made that it works for you. >+.B FakeClick >+can simulate mouse button press and release events and pass them >+to fvwm or the applications. The parameters are a list of >+commands which consist of pairs of >+.I command >+tokens and integer >+.I values, >+The >+.IR press " and " release >+commands are followed by the appropriate mouse button number and >+generate a button press or release event on the window below the >+pointer. The >+.I wait >+commands pauses fvwm for the given number of milliseconds. The >+.I modifiers >+command simulates pressing or releasing modifier keys. The values >+1 to 5 are mapped to >+.SM Mod1 >+to >+.SM Mod5 >+while 6, 7 and 8 are mapped to >+.SM Shift, >+.SM Lock >+and >+.SM Control. >+The modifier is set for any further button events. To release a >+modifier key, use the corresponding negative number. The >+.I depth >+command determines to which window the button events are sent. >+With a depth of 1, all events go to the root window, regardless of >+the pointer's position. With 2, the event is passed to the top >+level window under the pointer which is usually the frame window. >+With 3, events go to the client window. Higher numbers go to >+successive sub windows. Zero (0) goes to the smallest window that >+contains the pointer. Note that events propagate upward. >+.EX >+ FakeClick depth 2 press 1 wait 250 release 1 >+.EE >+This simulates a click with button 1 in the parent window (depth >+2) with a delay of 250 milliseconds between the press and the >+release. >+ >+.TP >+.BI "GlobalOpts [" options "]" >+As announced in the past, this command has been removed. Please >+replace the global options in your configuration file according to >+the following table: >+.EX >+GlobalOpts WindowShadeShrinks >+ --> >+Style * WindowShadeShrinks >+ >+GlobalOpts WindowShadeScrolls >+ --> >+Style * WindowShadeScrolls >+ >+GlobalOpts SmartPlacementIsReallySmart >+ --> >+Style * MinOverlapPlacement >+ >+GlobalOpts SmartPlacementIsNormal >+ --> >+Style * TileCascadePlacement >+ >+GlobalOpts ClickToFocusDoesntPassClick >+ --> >+Style * ClickToFocusPassesClickOff >+ >+GlobalOpts ClickToFocusPassesClick >+ --> >+Style * ClickToFocusPassesClick >+ >+GlobalOpts ClickToFocusDoesntRaise >+ --> >+Style * ClickToFocusRaisesOff >+ >+GlobalOpts ClickToFocusRaises >+ --> >+Style * ClickToFocusRaises >+ >+GlobalOpts MouseFocusClickDoesntRaise >+ --> >+Style * MouseFocusClickRaisesOff >+ >+GlobalOpts MouseFocusClickRaises >+ --> >+Style * MouseFocusClickRaises >+ >+GlobalOpts NoStipledTitles >+ --> >+Style * StippledTitleOff >+ >+GlobalOpts StipledTitles >+ --> >+Style * StippledTitle >+ >+GlobalOpts CaptureHonorsStartsOnPage >+ --> >+Style * CaptureHonorsStartsOnPage >+ >+GlobalOpts CaptureIgnoresStartsOnPage >+ --> >+Style * CaptureIgnoresStartsOnPage >+ >+GlobalOpts RecaptureHonorsStartsOnPage >+ --> >+Style * RecaptureHonorsStartsOnPage >+ >+GlobalOpts RecaptureIgnoresStartsOnPage >+ --> >+Style * RecaptureIgnoresStartsOnPage >+ >+GlobalOpts ActivePlacementHonorsStartsOnPage >+ --> >+Style * ManualPlacementHonorsStartsOnPage >+ >+GlobalOpts ActivePlacementIgnoresStartsOnPage >+ --> >+Style * ManualPlacementIgnoresStartsOnPage >+ >+GlobalOpts RaiseOverNativeWindows >+ --> >+BugOpts RaiseOverNativeWindows on >+ >+GlobalOpts IgnoreNativeWindows >+ --> >+BugOpts RaiseOverNativeWindows off >+ >+.EE >+ >+.TP >+.BI "HilightColor " "textcolor backgroundcolor" >+This command is obsoleted by the >+.B Style >+options >+.IR HilightFore " and " HilightBack . >+Please use >+.EX >+Style * HilightFore textcolor, \\ >+ HilightBack backgroundcolor >+.EE >+instead. >+ >+.TP >+.BI "HilightColorset [" num "]" >+This command is obsoleted by the >+.B Style >+option >+.IR HilightColorset . >+Please use >+.EX >+Style * HilightColorset num >+.EE >+instead. >+ >+.TP >+.BI "IconFont [" fontname "]" >+This command is obsoleted by the >+.B Style >+option >+.IR IconFont . >+Please use >+.EX >+Style * IconFont fontname >+.EE >+instead. >+ >+.TP >+.BI "IconPath " path >+This command is obsolete. Please use >+.B ImagePath >+instead. >+ >+.TP >+.BI "ImagePath " path >+Specifies a colon separated list of directories in which to search >+for images (both monochrome and pixmap). To find an image given >+by a relative pathname, fvwm looks into each directory listed in >+turn, and uses the first file found. >+ >+The >+.I path >+may contain environment variables such as >+.IR $HOME " (or " ${HOME} ). >+Further, a '+' in the >+.I path >+is expanded to the previous value of the path, allowing appending >+or prepending to the path easily. >+ >+For example: >+.EX >+ImagePath $HOME/icons:+:/usr/include/X11/bitmaps >+.EE >+Note: if the >+.B FvwmM4 >+module is used to parse your >+.I .fvwm2rc >+files, then m4 may want to mangle the word "include" which >+frequently shows up in the >+.B ImagePath >+command. To fix this one may add >+.EX >+undefine(`include') >+.EE >+prior to the >+.B ImagePath >+command, or better: use the >+.I -m4-prefix >+option to force all >+.B m4 >+directives to have a prefix of "m4_" (see the >+.B FvwmM4 >+man page). >+ >+.TP >+.BI "PixmapPath " path >+This command is obsolete. Please use >+.B ImagePath >+instead. >+ >+.TP >+.BI "WindowFont [" fontname "]" >+This command is obsoleted by the >+.B Style >+option >+.IR Font . >+Please use >+.EX >+Style * Font fontname >+.EE >+instead. >+ >+.IP "\fBWindowList [(\fP \fIconditions\fP \ >+\fB)] [\fP \fIposition\fP \ >+\fB] [\fP \fIoptions\fP \ >+\fB] [\fP \fIdouble-click-action\fP \ >+\fB]\fP" >+Generates a pop-up menu (and pops it up) in which the title and >+geometry of each of the windows currently on the desktop are >+shown. >+ >+The format of the geometry part is: >+. IR desk "(" layer "): " "x-geometry sticky" , >+where >+.IR desk " and " layer >+are the corresponding numbers and >+.I sticky >+is empty or a capital S. The geometry of iconified windows is >+shown in parentheses. Selecting an item from the window list >+pop-up menu causes the interpreted function "WindowListFunc" to be >+run with the window id of that window passed in as $0. The default >+"WindowListFunc" looks like this: >+.EX >+AddToFunc WindowListFunc >+ + I WindowId $0 Iconify off >+ + I WindowId $0 FlipFocus >+ + I WindowId $0 Raise >+ + I WindowId $0 WarpToWindow 5p 5p >+.EE >+You can destroy the builtin "WindowListFunc" and create your own >+if these defaults do not suit you. >+ >+The window list menu uses the "WindowList" menu style if it is >+defined (see >+.B MenuStyle >+command). Otherwise the default menu style is used. To switch >+back to the default menu style, issue the command >+.EX >+DestroyMenuStyle WindowList >+.EE >+Example: >+.EX >+MenuStyle WindowList SelectOnRelease Meta_L >+.EE >+The >+.I conditions >+can be used to exclude certain windows from the window >+list. Please refer to the >+.B Current >+command for details. Only windows that match the given conditions >+are displayed in the window list. The >+.I options >+below work vice versa: windows that would otherwise not be >+included in the window list can be selected with them. The >+.I conditions >+always override the >+.IR options . >+ >+ >+The >+.I position >+arguments are the same as for >+.BR Menu . >+The command >+.I double-click-action >+is invoked if the user double-clicks (or hits the key rapidly >+twice if the menu is bound to a key) when bringing the window >+list. The >+.I double-click-action >+must be quoted if it consists of more than one word. >+ >+The >+.I double-click-action >+is useful to define a default window if you have bound the window >+list to a key (or button) like this: >+.EX >+# Here we call an existing function, but it may be different >+AddToFunc SwitchToWindow >++ I WindowListFunc $w >+ >+Key Tab A M WindowList "Prev SwitchToWindow" >+.EE >+Hitting >+.SM Alt-Tab >+once it brings up the window list, if you hit it twice the focus >+is flipped between the current and the last focused window. With >+the proper >+.I SelectOnRelease >+menu style (see example above) a window is selected as soon as you >+release the >+.SM Alt >+key. >+ >+The >+.I options >+passed to WindowList can be >+.IR NoGeometry , >+.IR NoGeometryWithInfo , >+.IR "Function funcname" , >+.IR "Desk desknum" , >+.IR CurrentDesk , >+.IR NoIcons " / " Icons " / " OnlyIcons , >+.IR NoNormal " / " Normal " / " OnlyNormal , >+.IR NoSticky " / " Sticky " / " OnlySticky , >+.IR NoOnTop " / " OnTop " / " OnlyOnTop , >+.IR NoOnBottom " / " OnBottom " / " OnlyOnBottom , >+.IR "Layer m [n]" , >+.IR UseListSkip " / " OnlyListSkip , >+.IR NoDeskSort , >+.IR ReverseOrder , >+.IR UseIconName , >+.IR Alphabetic " / " NotAlphabetic , >+.IR NoHotkeys , >+.IR SelectOnRelease . >+ >+(Note - normal means not iconic, sticky, or on top) >+ >+The >+.I SelectOnRelease >+option works exactly like the >+.B MenuStyle >+option with the same name, but overrides the option given in a >+menu style. By default, this option is set to the left >+.SM Alt >+key. To switch it off, use >+.I SelectOnRelease >+without a key name. >+ >+If you pass in a function via >+.IR "Function funcname" , >+$0 is the window id: >+.EX >+AddToFunc IFunc I WindowId $0 Iconify toggle >+WindowList Function IFunc, NoSticky, \\ >+ CurrentDesk, NoIcons >+.EE >+If you use the >+.IB "Layer m " [ "n" ] >+option, only windows in layers between m and n are displayed. n >+defaults to m. With the >+.I ReverseOrder >+option the order of the windows in the list is reversed. >+ >+If you wanted to use the >+.B WindowList >+as an icon manager, you could invoke the following: >+.EX >+WindowList OnlyIcons, Sticky, OnTop, Geometry >+.EE >+(Note - the >+.I Only >+options essentially wipe out all other ones... but the >+.I OnlyListSkip >+option which just causes >+.B WindowList >+to only consider the windows with >+.I WindowListSkip >+style.) >+ >+.TP >+.BI "+" >+Used to continue adding to the last specified decor, function or >+menu. See the discussion for >+.BR AddToDecor ", " AddToFunc ", and " AddToMenu . >+ >+ >+.SS COMMANDS AFFECTING WINDOW MOVEMENT AND PLACEMENT >+ >+.TP >+.BI "AnimatedMove " "x y" " [" Warp "]" >+Move a window in an animated fashion. Similar to >+.B Move >+command below. The options are the same, except they are required, >+since it doesn't make sense to have a user move the window >+interactively and animatedly. If the optional argument >+.I Warp >+is specified the pointer is warped with the window. >+ >+.TP >+.BI "HideGeometryWindow [" Never | Move | Resize "]" >+Hides the position or size window that is usually shown when a >+window is moved or resized interactively. To switch it off only >+for move or resize operations the optional parameters >+.IR Move " and " Resize >+can be used respectively. To switch both on again use the >+.I Never >+option. >+ >+.TP >+.BI "Layer [" "arg1 arg2" "] | [" default "]" >+Puts the current window in a new layer. If >+.I arg1 >+is non zero then the next layer is the current layer number plus >+.IR arg1 . >+If >+.I arg1 >+is zero then the new layer is >+.IR arg2 . >+ >+As a special case, >+.I default >+puts the window in its default layer, i.e. the layer it was >+initially in. The same happens if no or invalid arguments are >+specified. >+ >+.TP >+.BI "Lower" >+Allows the user to lower a window. Note that this lowers a window >+only in its layer. To bring a window to the absolute bottom, use >+.EX >+AddToFunc lower-to-bottom >+ + I Layer 0 0 >+ + I Lower >+.EE >+ >+.IP "\fBMove [[\fP \fIw\fP \ >+\fB|\fP \fIm\fP \ >+\fB]\fP \fIx\fP \ >+\fB[\fP \fIp\fP \ >+\fB] [\fP \fIw\fP \ >+\fB|\fP \fIm\fP \ >+\fB]\fP \fIy\fP \ >+\fB[\fP \fIp\fP \ >+\fB] [\fP \fIWarp\fP \ >+\fB]] | [\fP \fIpointer\fP \ >+\fB]\fP" >+Allows the user to move a window. If called from somewhere in a >+window or its border, then that window is moved. If called from >+the root window then the user is allowed to select the target >+window. If the optional argument >+.I Warp >+is specified the pointer is warped with the window. If the single >+argument >+.I pointer >+is given, the top left corner of the window window is moved to the >+pointer position before starting the operation; this is mainly >+intended for internal use by modules like >+.BR FvwmPager . >+ >+The operation can be aborted with Escape or by pressing mouse >+button 2. Pressing button 3 sets the >+.I PlacedByButton3 >+condition (see >+.B Current >+command). >+ >+If the optional arguments >+.IR x " and " y >+are provided, then the window is moved immediately without user >+interaction. Each argument can specify an absolute or relative >+position from either the left/top or right/bottom of the screen. >+By default, the numeric value given is interpreted as a percentage >+of the screen width/height, but a trailing >+.RI ' p ' >+changes the interpretation to mean pixels. To move the window >+relative to its current position, add the >+.RI ' w ' >+(for "window") prefix before the >+. IR x " and/or " y >+value. To move the window to a position relative to the current >+location of the pointer, add the >+.RI ' m ' >+(for "mouse") prefix. To leave either coordinate unchanged, >+"keep" can be specified in place of >+.IR x " or " y . >+ >+Simple Examples: >+.EX >+# Interactive move >+Mouse 1 T A Move >+# Move window so top left is at (10%,10%) >+Mouse 2 T A Move 10 10 >+# Move top left to (10pixels,10pixels) >+Mouse 3 T A Move 10p 10p >+.EE >+More complex examples (these can be bound as actions to >+keystrokes, etc.; only the command is shown, though): >+.EX >+# Move window so bottom right is at bottom >+# right of screen >+Move -0 -0 >+ >+# Move window 5% to the right, and to the >+# middle vertically >+Move w+5 50 >+ >+# Move window up 10 pixels, and so left edge >+# is at x=40 pixels >+Move 40p w-10p >+ >+# Move window to the mouse pointer location >+# >+Move m+0 m+0 >+.EE >+See also the >+.B AnimatedMove >+command above. >+ >+.TP >+.BI "MoveToDesk " prev " | " arg1 " [" arg2 "] [" "min max" "]" >+Moves the selected window to another desktop. The arguments are >+the same as for the >+.B GotoDesk >+command. >+.B MoveToDesk >+is a replacement for the old >+.B WindowsDesk >+command, which can no longer be used. >+ >+.TP >+.BI "MoveThreshold [" pixels "]" >+When the user presses a mouse button upon an object fvwm waits to >+see if the action is a click or a drag. If the mouse moves by >+more than >+.I pixels >+pixels it is assumed to be a drag. >+ >+Previous versions of fvwm hardwired >+.I pixels >+to 3, which is now the default value. If >+.I pixels >+is negative or omitted the default value (which might be increased >+when 16000x9000 pixel displays become affordable) is restored. >+ >+.IP "\fBMoveToPage [\fP \fIx\fP \ >+\fB[\fP \fIp\fP \ >+\fB]\fP \fIy\fP \ >+\fB[\fP \fIp\fP \ >+\fB]] | [\fIprev\fP \ >+\fB]\fP" >+Moves the selected window to another page (x,y). The upper left >+page is (0,0), the upper right is (M,0), where M is one less than >+the current number of horizontal pages specified in the >+.B DeskTopSize >+command. Similarly the lower left page is (0,N), and the lower >+right page is (M,N). Negative page numbers refer to pages from >+the rightmost/lowest page. If >+.IR x " and " y >+are not given, the window is moved to the current page (a window >+that has the focus but is off-screen can be retrieved with this). >+Moving windows to a page relative to the current one can be >+achieved by adding a trailing >+.RI ' p ' >+after any or both numerical arguments. To move a window to the >+previous page use >+.I prev >+as the single argument. Using MoveToPage on a sticky window makes >+the window non-sticky (see >+.B Stick >+command). >+ >+Examples: >+.EX >+# Move window to page (2,3) >+MoveToPage 2 3 >+ >+# Move window to lowest and rightmost page >+MoveToPage -1 -1 >+ >+# Move window to last page visited >+MoveToPage prev >+ >+# Move window two pages to the right and one >+# page up >+MoveToPage +2p -1p >+.EE >+ >+.TP >+.BI "MoveToScreen [ " screen " ]" >+Moves the selected window to another Xinerama screen. The >+.I screen >+argument can be 'p' for the primary screen, 'c' for the current >+screen (containing the mouse pointer), 'g' for the global screen >+or the screen number itself (counting from zero). >+ >+.TP >+.BI "OpaqueMoveSize [" percentage "]" >+Tells fvwm the maximum size window with which opaque window >+movement should be used. The percentage is percent of the total >+screen area (may be greater than 100). With >+.EX >+OpaqueMoveSize 0 >+.EE >+all windows are moved using the traditional rubber-band >+outline. With >+.EX >+OpaqueMoveSize unlimited >+.EE >+or if a negative percentage is given >+all windows are moved as solid windows. The default is >+.EX >+OpaqueMoveSize 5 >+.EE >+which allows small windows to be moved in an opaque manner but >+large windows are moved as rubber-bands. If >+.I percentage >+is omitted or invalid the default value is set. To resize windows >+in an opaque manner you can use the >+.I ResizeOpaque >+style. See >+.B Style >+command. >+ >+.TP >+.BI "PlaceAgain [" Anim "]" >+Causes the current window's position to be re-computed using the >+initial window placement logic. The window is moved to where it >+would have been if it were a new window that had just appeared. >+Most useful with >+.IR Smart " or " Clever " (" ReallySmart ")" >+placement. If the optional argument >+.I Anim >+is specified, an animated move is used to place the window in its >+new position. >+ >+.TP >+.BI "Raise" >+Allows the user to raise a window. Note that this raises a window >+only in its layer. To bring a window to the absolute top, use >+.EX >+AddToFunc raise-to-top >+ + I Layer 0 ontop >+ + I Raise >+.EE >+where ontop is the highest layer used in your setup. >+ >+.TP >+.BI "RaiseLower" >+Alternately raises and lowers a window. The window is raised if >+it is obscured by any window (except for its own transients when >+.I RaiseTransient >+style is used; see >+.B Style >+command) otherwise it is lowered. >+ >+.IP "\fBResize [\fP \fIwidth\fP \ >+\fB[\fP \fIp\fP \ >+\fB|\fP \fIc\fP \ >+\fB]\fP \fIheight\fP \ >+\fB[\fP \fIp\fP \ >+\fB|\fP \fIc\fP \ >+\fB]] | [\fP \fIbottomright\fP \ >+\fB|\fP \fIbr x y\fP \ >+\fB]\fP" >+Allows to resize a window. If called from somewhere in a window >+or its border, then that window is resized. If called from the >+root window then the user is allowed to select the target window. >+ >+The operation can be aborted with Escape or by pressing any mouse >+button (except button 1 which confirms it). >+ >+If the optional arguments >+.IR width " and " height >+are provided, then the window is resized so that its dimensions >+are >+.IR width " by " height . >+The units of >+.IR width " and " height >+are percent-of-screen, unless a letter >+.RI ' p ' >+is appended to one or both coordinates, in which case the location >+is specified in pixels. With a >+.RI ' c ' >+suffix the unit defined by the client application (hence the c) is >+used. So you can say >+.EX >+Resize 80c 24c >+.EE >+to make a terminal window just big enough for 80x24 >+characters. Both, >+.IR width " and " height >+can be negative. In this case the new size is the screen size >+minus the given value. If either value is "keep", the >+corresponding dimension of the window is left untouched. >+ >+An alternate syntax is used if the keyword >+.IR bottomright " or in short " br >+follows the command name. In this case, the arguments >+.IR x " and " y >+specify the desired position of the bottom right corner of the >+window. They are interpreted exactly like the >+.IR x " and " y >+arguments of the >+.B Move >+command. >+ >+.TP >+.BI "ResizeMove " "resize-arguments move-arguments" >+This command does the same as the >+.BR Resize " and " Move >+commands, but in a single call which is less visually >+disturbing. The >+.I resize-arguments >+are exactly the same arguments as for the >+.B Resize >+command and the >+.I move-arguments >+are exactly the same arguments as for the >+.B Move >+command except the >+.I pointer >+option which is not supported by the >+.B ResizeMove >+command. >+ >+Example: >+.EX >+# Move the window to the top left corner >+ResizeMove w+0 -10p 0 -20p >+.EE >+ >+.TP >+.BI "SetAnimation " milliseconds-delay " [" fractions-to-move-list "]" >+Sets the time between frames and the list of fractional offsets to >+customize the animated moves of the >+.B AnimatedMove >+command and the animation of menus (if the menu style is set to >+animated; see >+.B MenuStyle >+command). If the >+.I fractions-to-move-list >+is omitted, only the time between frames is altered. The >+.I fractions-to-move-list >+specifies how far the window should be offset at each successive >+frame as a fraction of the difference between the starting >+location and the ending location. e.g.: >+.EX >+SetAnimation 10 -.01 0 .01 .03 .08 .18 .3 \\ >+ .45 .6 .75 .85 .90 .94 .97 .99 1.0 >+.EE >+Sets the delay between frames to 10 milliseconds, and sets the >+positions of the 16 frames of the animation motion. Negative >+values are allowed, and in particular can be used to make the >+motion appear more cartoonish, by briefly moving slightly in the >+opposite direction of the main motion. The above settings are the >+default. >+ >+.IP "\fBSnapAttraction [\fP \fIproximity\fP \ >+\fB[\fP \fIbehavior\fP \ >+\fB] [\fP \fIScreen\fP \ >+\fB]]\fP" >+If during an interactive move the window or icon comes within >+.I proximity >+pixels of another the window or icon, it is moved to make the >+borders adjoin. The default of 0 means that no snapping happens. >+Calling this command without arguments turns off snap attraction >+and restores the default behavior. Please refer also to the >+.B SnapGrid >+command. >+ >+The >+.I behavior >+argument is optional and may be set to one of the four following >+values: With >+.I All >+both icons and windows snap to other windows and other icons. >+.I SameType >+lets snap windows only to other windows and icons only to other >+icons. With >+.I Windows >+windows snap only to other windows. Icons do not snap. Similarly >+with >+.I Icons >+icons snap to only other icons and windows do not snap. >+ >+If the >+.I behavior >+option is not given, the snapping behavior is not changed. The >+default behavior is >+.IR All . >+ >+If the >+.I Screen >+option is present windows and or icons are snapped to the screen >+edges too. >+ >+.TP >+.BI "SnapGrid [" "x-grid-size y-grid-size" "]" >+During an interactive move a window or icon is positioned such >+that its location (top left corner) is coincident with the nearest >+grid point. The default >+.IR x-grid-size " and " y-grid-size >+setting are both 1, which is effectively no grid all. An >+interactive move with both >+.BR SnapGrid " and " SnapAttraction >+results in the window being moved to be adjacent to the nearest >+window border (if within snap proximity) or grid position. In >+other words, the window moves the shortest distance possible to >+satisfy both >+.BR SnapGrid " and " SnapAttraction . >+Note that the x and y coordinates are not coupled. For example, a >+window may snap to another window on the x axis while snapping to >+a grid point on the y axis. Calling this command without >+arguments reinstates the default settings. >+ >+.TP >+.BI "WindowsDesk " arg1 " [" arg2 "]" >+Moves the selected window to another desktop. >+ >+This command has been removed and must be replaced by >+.BR MoveToDesk , >+the arguments for which are the same as for the >+.B GotoDesk >+command. >+.B Important note: >+You cannot simply change the name of the command: the syntax has >+changed. If you used >+.EX >+WindowsDesk n >+.EE >+to move a window to desk n, you have to change it to >+.EX >+MoveToDesk 0 n >+.EE >+ >+.TP >+.BI "XorPixmap [" pixmap "]" >+Selects the pixmap with which bits are xor'ed when doing >+rubber-band window moving or resizing. This has a better chance >+of making the rubber-band visible if >+.B XorValue >+does not give good results. An example pixmap >+.I resize.rainbow.xpm >+is provided with the icon distribution. To turn the >+.B XorPixmap >+off again use the >+.B XorValue >+command or omit the >+.I pixmap >+argument. >+ >+.TP >+.BI "XorValue [" number "]" >+Changes the value with which bits are xor'ed when doing >+rubber-band window moving or resizing. Setting this value is a >+trial-and-error process. The default value 0 tries to find a >+value that gives a good contrast to black and white. It is set if >+the given >+.I number >+is omitted or invalid. >+ >+ >+.SS COMMANDS FOR FOCUS AND MOUSE MOVEMENT >+ >+.TP >+.BI "CursorMove " horizontal "[" p "] " vertical "[" p "]" >+Moves the mouse pointer by >+.I horizontal >+pages in the X direction and >+.I vertical >+pages in the Y direction. Either or both entries may be >+negative. Both horizontal and vertical values are expressed in >+percent of pages, so >+.EX >+CursorMove 100 100 >+.EE >+means to move down and right by one full page. >+.EX >+CursorMove 50 25 >+.EE >+means to move right half a page and down a quarter of a >+page. Alternatively, the distance can be specified in pixels by >+appending a >+.RI ' p ' >+to the horizontal and/or vertical specification. For example >+.EX >+CursorMove -10p -10p >+.EE >+means move ten pixels up and ten pixels left. The CursorMove >+function should not be called from pop-up menus. >+ >+.TP >+.BI "FlipFocus [" NoWarp "]" >+Executes a >+.B Focus >+command as if the user had used the pointer to select the >+window. This command alters the order of the WindowList in the >+same way as clicking in a window to focus, i.e. the target window >+is removed from the >+.B WindowList >+and placed at the start. This command is recommended for use with >+the >+.B Direction >+command and in the function invoked from >+.BR WindowList . >+ >+.TP >+.BI "Focus [" NoWarp "]" >+Sets the keyboard focus to the selected window. If the >+.I NoWarp >+argument is given, this is all it does. Otherwise it also moves >+the viewport or window as needed to make the selected window >+visible. This command does not automatically raise the >+window. Does not warp the pointer into the selected window (see >+.B WarpToWindow >+function). Does not de-iconify. This command does not alter the >+order of the >+.BR WindowList , >+it rotates the >+.B WindowList >+around so that the target window is at the start. >+ >+When the >+.I NoWarp >+argument is given, Focus cannot transfer the keyboard focus to >+windows on other desks. >+ >+To raise and/or warp a pointer to a window together with >+.BR Focus " or " FlipFocus , >+use a function, like: >+.EX >+AddToFunc SelectWindow >++ I Focus >++ I Iconify false >++ I Raise >++ I WarpToWindow 50 8p >+.EE >+ >+.TP >+.BI "WarpToWindow " x "[" p "] " y "[" p "]" >+Warps the cursor to the associated window. The parameters >+.IR x " and " y >+default to percentage of window down and in from the upper left >+hand corner (or number of pixels down and in if >+.RI ' p ' >+is appended to the numbers). If a number is negative the opposite >+edge is used and the direction reversed. This command works also >+with windows that are not managed by fvwm. In this case fvwm does >+not bring the window onto the screen if it is not visible. For >+example it is possible to warp the pointer to the center of the >+root window on screen 1: >+.EX >+WindowId root 1 WarpToWindow 50 50 >+.EE >+ >+ >+.SS COMMANDS CONTROLLING WINDOW STATE >+ >+.TP >+.BI "Close" >+If the window accepts the delete window protocol a message is sent >+to the window asking it to gracefully remove itself. If the >+window does not understand the delete window protocol then the >+window is destroyed as with the >+.B Destroy >+command. Note: if the window accepts the delete window protocol >+but does not close itself in response, the window is not deleted. >+ >+.TP >+.BI "Delete" >+Sends a message to a window asking that it remove itself, >+frequently causing the application to exit. >+ >+.TP >+.BI "Destroy" >+Destroys an application window, which usually causes the >+application to crash and burn. >+ >+.TP >+.BI "Iconify [" bool "]" >+Iconifies a window if it is not already iconified or de-iconifies >+it if it is already iconified. The optional argument >+.I bool >+is a boolean argument. "True" means only iconification is >+allowed, while "False" forces de-iconification. Using "toggle" >+switches between iconified and de-iconified states. >+ >+There are a number of >+.B Style >+options which influence the appearance and behavior of icons (e.g. >+.IR StickyIcon ", " NoIcon ). >+ >+For backwards compatibility, the optional argument may also be a >+positive number instead of "True", or a negative number instead of >+"False". Note that this syntax is obsolete, and will be removed >+in the future. >+ >+.IP "\fBMaximize [\fP\fIscreen screen-spec\fP\fB] \ >+[\fP\fIbool\fP\fB] \ >+[\fP\fIhorizontal\fP\fB[\fP\fIp\fP\fB]\fP \ >+\fIvertical\fP\fB[\fP\fIp\fP\fB]]\fP" >+Without its optional arguments (or if the >+.I bool >+bit has the value "toggle") >+.B Maximize >+causes the window to alternately switch from a full-screen size to >+its normal size. To force a window into maximized (normal) state >+you can use a "True" or "False" value for the >+.I bool >+argument. >+ >+With the optional arguments >+.IR horizontal " and " vertical , >+which are expressed as percentage of a full screen, the user can >+control the new size of the window. An optional suffix >+.RI ' p ' >+can be used to indicate pixels instead of percents of the screen >+size. If horizontal is greater than 0 then the horizontal >+dimension of the window is set to >+.IR horizontal *screen_width/100. >+If the value is smaller than 0 the size is subtracted from the >+screen width, i.e. -25 is the same as 75. If >+.I horizontal >+is "grow", it is maximized to current available space until >+finding any obstacle. The vertical resizing is similar. If both >+horizontal and vertical values are "grow", it expands vertically >+first, then horizontally to find space. Instead of the horizontal >+"grow" argument, "growleft" or "growright" can be used >+respectively "growup" and "growdown". For example, the following >+adds a title-bar button to switch a window to the full vertical >+size of the screen: >+.EX >+Mouse 0 4 A Maximize 0 100 >+.EE >+The following causes windows to be stretched to the full width: >+.EX >+Mouse 0 4 A Maximize 100 0 >+.EE >+This makes a window that is half the screen size in each >+direction: >+.EX >+Mouse 0 4 A Maximize 50 50 >+.EE >+To expand a window horizontally until any other window is found: >+.EX >+Mouse 0 4 A Maximize 0 grow >+.EE >+To expand a window but leave the lower 60 pixels of the screen >+unoccupied >+.EX >+Mouse 0 4 A Maximize 100 -60p >+.EE >+Values larger than 100 can be used with caution. >+ >+If the first argument is the word >+.IR screen , >+the >+.I screen-spec >+argument specifies the Xinerama screen on which to operate. >+It can be 'p' for the primary screen, 'c' for the current >+screen (containing the mouse pointer), 'g' for the global screen >+or the screen number itself (counting from zero). This option is >+only useful with multiple Xinerama screens. >+ >+.TP >+.BI "Recapture" >+Causes fvwm to recapture all of its windows. This ensures that >+the latest style parameters are used. The recapture operation is >+visually disturbing. >+ >+Since fvwm version 2.4 only a very few >+.B Style >+options need a >+.B Recapture >+to take effect (e.g. >+.IR UseStyle ). >+ >+.TP >+.BI "RecaptureWindow" >+Causes fvwm to recapture the chosen window. See >+.B Recapture >+command above. >+ >+.TP >+.BI "Refresh" >+Causes all windows on the screen to redraw themselves. All pending >+updates of all windows' styles and looks are applied immediately. >+E.g. if >+.BR Style " or " TitleStyle >+commands were issued inside a fvwm function. >+ >+.TP >+.BI "RefreshWindow" >+Causes the chosen window to redraw itself. All pending updates of >+the window's style and looks are applied immediately. E.g. if >+.BR Style " or " TitleStyle >+commands were issued inside a fvwm function. >+ >+.TP >+.BI "Stick [" bool "]" >+If the >+.I bool >+argument is empty or "toggle", the >+.B Stick >+command makes a window sticky if it is not already sticky, or >+non-sticky if it is already sticky. To make a window sticky >+regardless of its current state the >+.I bool >+argument must be "True". To make it non-sticky use "False". >+ >+.TP >+.BI "WindowShade [" bool "]" >+Toggles the window shade feature for titled windows. Windows in >+the shaded state only display a title-bar. If >+.I bool >+is not given or "toggle", the window shade state is toggled. If >+.I bool >+is "True", the window is forced to the shaded state. If >+.I bool >+is "False", then the window is forced to the non-shaded >+state. Windows without titles can be shaded too. See also >+.I WindowShadeSteps >+option of the >+.B Style >+command. >+ >+For backwards compatibility, the optional argument may also be 1 >+to signify "on", and 2 to signify "off". Note that this syntax is >+obsolete, and will be removed in the future. >+ >+.TP >+.BI "WindowShadeAnimate [" steps "[" p "]]" >+This command is obsolete. Please use the >+.I WindowShadeSteps >+option of the >+.B Style >+command instead. >+ >+ >+.SS COMMANDS FOR MOUSE, KEY AND STROKE BINDINGS >+ >+.TP >+.BI "IgnoreModifiers [" Modifiers "]" >+Tells fvwm which modifiers to ignore when matching Mouse or Key >+bindings. >+.B IgnoreModifiers >+affects the >+.I ClickToFocus >+style too. This command belongs into your >+.IR .fvwm2rc . >+If you issue it when your fvwm session is already up and running >+the results are unpredictable. The should appear before any >+applications or modules are started in your >+.I .fvwm2rc >+file (e.g. with the >+.B Exec >+command). >+ >+.I Modifiers >+has the same syntax as in the >+.BR Mouse " or " Key >+bindings, with the addition of 'L' meaning the >+.SM caps lock >+key. The default is "L". >+.I Modifiers >+can be omitted, meaning no modifiers are ignored. This command >+comes in handy if the >+.SM num-lock >+and >+.SM scroll-lock >+keys interfere with your shortcuts. With XFree86 '2' usually is >+the >+.SM num-lock >+modifier and '5' refers to the >+.SM scroll-lock >+key. To turn all these pesky modifiers off you can use this >+command: >+.EX >+IgnoreModifiers L25 >+.EE >+.I Important Note: >+This command creates a lot of extra network traffic, depending on >+your CPU, network connection, the number of >+.BR Key " or " Mouse >+commands in your configuration file and the number of modifiers you >+want to ignore. If you do not have a lightning fast machine or >+very few bindings you should not ignore more than two modifiers. >+I.e. do not ignore >+.SM scroll-lock >+if you have no problem with it. In the >+.I FAQ >+you can find a better solution of this problem. >+ >+.TP >+.BI "GnomeButton" >+Used in conjunction with >+.B Mouse >+to pass mouse button presses on the root window to a >+.SM GNOME >+program (such as GMC). The following example passes presses of >+mouse buttons 1 and 3 to such a program. >+.EX >+Mouse 1 R A GnomeButton >+Mouse 3 R A GnomeButton >+.EE >+ >+.TP >+.BI "Key " "Keyname Context Modifiers Function" >+Binds a keyboard key to a specified fvwm built-in function, or >+removes the binding if >+.I Function >+is '-'. The syntax is the same as for a >+.B Mouse >+binding except that the mouse button number is replaced with a >+.IR Keyname . >+The >+.I Keyname >+is one of the entries from >+.IR /usr/include/X11/keysymdef.h , >+with the leading XK_ omitted. The >+.IR Context " and " Modifiers >+fields are defined as in the >+.B Mouse >+binding. However, when you press a key the context window is the >+window that has the keyboard focus. That is not necessarily the >+same as the window the pointer is over (with >+.IR SloppyFocus " or " ClickToFocus ). >+Note that key bindings with the 'R' (root window) context do not >+work properly with >+.IR SloppyFocus " and " ClickToFocus . >+If you encounter problems, use the >+.B PointerKey >+command instead. If you want to bind keys to a window with >+.IR SloppyFocus " or " ClickToFocus >+that are supposed to work when the pointer is not over the window, >+fvwm assumes the pointer is over the client window (i.e. you have >+to use the 'W' modifier). >+ >+The following example binds the built in window list to pop up >+when >+.SM Alt-Ctrl-Shift-F11 >+is hit, no matter where the mouse pointer is: >+.EX >+Key F11 A SCM WindowList >+.EE >+Binding a key to a title-bar button causes that button to appear. >+Please refer to the >+.B Mouse >+command for details. >+ >+.TP >+.BI "Mouse " "Button Context Modifiers Function" >+Defines a mouse binding, or removes the binding if >+.I Function >+is '-'. >+.I Button >+is the mouse button number. If >+.I Button >+is zero then any button performs the specified function. >+.I Context >+describes where the binding applies. Valid contexts are 'R' for >+the root window, 'W' for an application window, 'T' for a window >+title-bar, 'S' for a window side, top, or bottom bar, 'F' for a >+window frame (the corners), 'I' for an Icon window, or '0' through >+'9' for title-bar buttons, or any combination of these letters. >+'A' is for any context except for title-bar buttons. For >+instance, a context of "FST" applies when the mouse is anywhere in >+a window's border except the title-bar buttons. Only 'S' and 'W' >+are valid for an undecorated window. >+ >+.I Modifiers >+is any combination of 'N' for no modifiers, 'C' for control, 'S' >+for shift, 'M' for Meta, 'L' for Caps-Lock or 'A' for any >+modifier. For example, a modifier of "SM" applies when both the >+.SM Meta >+and >+.SM Shift >+keys are down. X11 modifiers mod1 through mod5 are represented as >+the digits '1' through '5'. The modifier 'L' is ignored by >+default. To turn it on, use the >+.B IgnoreModifiers >+command. >+ >+.I Function >+is one of fvwm's built-in functions. >+ >+The title-bar buttons are numbered with odd numbered buttons on >+the left side of the title-bar and even numbers on the >+right. Smaller-numbered buttons are displayed toward the outside >+of the window while larger-numbered buttons appear toward the >+middle of the window (0 is short for 10). In summary, the buttons >+are numbered: >+.EX >+1 3 5 7 9 0 8 6 4 2 >+.EE >+The highest odd numbered button which has an action bound to it >+determines the number of buttons drawn on the left side of the >+title bar. The highest even number determines the number or right >+side buttons which are drawn. Actions can be bound to either >+mouse buttons or keyboard keys. >+ >+.TP >+.BI "PointerKey " "Keyname Context Modifiers Function" >+This command works exactly like the >+.B Key >+command. The only difference is that the binding operates on the >+window under the pointer. Normal key bindings operate on the >+focused window instead. The >+.B PointerKey >+command can for example be used to bind keys to the root window if >+you are using >+.IR SloppyFocus " or " ClickToFocus . >+However, some applications (xterm is one example) are unable to >+handle this key anymore, even if the pointer is over the xterm >+window. It is recommended to use the >+.B PointerKey >+command only for key combinations that are not needed in any >+application window. >+ >+Example: >+.EX >+Style * SloppyFocus >+PointerKey f1 a m Menu MainMenu >+.EE >+ >+.TP >+.BI "Stroke " "Sequence Button Context Modifiers Function" >+Binds a mouse stroke sequence to a specified fvwm built-in >+function, or removes the binding if >+.I Function >+is '-'. The syntax is the same as for a >+.B Mouse >+binding except that >+.I Sequence >+is inserted in front of the button number and a value of 0 for >+.I Button >+concerns the >+.B StrokeFunc >+command. The >+.IR Context " and " Modifiers >+fields are defined as in the >+.B Mouse >+binding. However, only the 'R' Context really works (if you want >+to use other contexts you need to use the >+.B StrokeFunc >+below). >+ >+Strokes sequences are defined in a telephone grid like this: >+.EX >+ 1 2 3 >+ >+ 4 5 6 >+ >+ 7 8 9 >+.EE >+or in a numeric pad grid like this: >+.EX >+ 7 8 9 >+ >+ 4 5 6 >+ >+ 1 2 3 >+.EE >+The telephone grid is used by default, to use the numeric pad grid >+you should begin the sequence with a 'N'. Note that a complex >+motion may gives several different sequences (see the "netscape" >+example below to handle such motion). Moreover, sequence are >+limited to 20 elements (with the present version of >+.BR libstroke ), >+however, in practice it is preferable to use sequence with less >+than 12 elements. >+ >+Because of the default button menu in fvwm, you may need to remove >+a mouse button binding (using an empty action) before using the >+stroke >+.EX >+Mouse 3 R N >+.EE >+Also, you can still use the stroke "sequence 0" to simulate a >+click: >+.EX >+Stroke 0 3 R N Menu WindowList Nop >+.EE >+The following example starts xterm when the mouse drags an 'I' on >+the root window with button 3 pressed down: >+.EX >+Stroke 258 3 R N Exec exec xterm >+.EE >+An example for Netscape: >+.EX >+Stroke 7415963 3 R N Exec exec netscape >+Stroke 74148963 3 R N Exec exec netscape >+Stroke 74158963 3 R N Exec exec netscape >+Stroke 7418963 3 R N Exec exec netscape >+Stroke 415963 3 R N Exec exec netscape >+.EE >+You may prefer to use the numeric pad grid since you have such a >+grid on your machine. Here an example: >+.EX >+Stroke N78963314 3 R N FvwmForm FvwmForm-QuitVerify >+Stroke N789633147 3 R N FvwmForm FvwmForm-QuitVerify >+.EE >+This example starts the "QuitVerify" form if you draw a box that >+begins in the top left corner. >+ >+Note: You need >+.B libstroke >+installed and fvwm compiled with stroke support. >+.B libstroke >+can be obtained at >+.EX >+.B http://www.etla.net/~willey/projects/libstroke/ >+.EE >+ >+.TP >+.BI "StrokeFunc [" Options "]" >+Causes fvwm to record a mouse stroke sequence and to execute the >+corresponding action as defined in a >+.B Stroke >+command. The cursor is modified to the >+.I STROKE >+context of the >+.B CursorStyle >+command during recording. When the stroke is finished >+.B StrokeFunc >+looks for a stroke binding of the form >+.EX >+Stroke sequence 0 Context Modifiers action >+.EE >+and executes the corresponding action (Note the 0). Normal use of this >+function is via a >+.BR Mouse " or " Key >+command. Examples: >+.EX >+Mouse 3 A M StrokeFunc >+Key x R N StrokeFunc >+.EE >+If you press mouse button 3 and >+.SM Alt >+anywhere (respectively, press the key x when the cursor is on the >+root window), then fvwm records the mouse motions until the mouse >+button 3 (respectively, the x key) is released and then check if >+the recorded >+.I sequence >+corresponds to a stroke binding of the form >+.EX >+.RI """Stroke " sequence " 0 A M " action """ \"" >+.RI """Stroke " sequence " 0 R N " action """ \"" >+.EE >+Note that the >+.IR Context " and " Modifiers >+are taken at the beginning of the execution of the >+.B StrokeFunc >+command (so you can release the modifiers before the end of the >+stroke recording in the case of a mouse binding and if you used, >+say, a title-bar context the mouse motion can go through an >+application window). The keys >+.SM Escape >+and >+.SM Delete >+allow you to abort the command. >+ >+The >+.B StrokeFunc >+command has five options: >+.IR NotStayPressed ", " EchoSequence ", " DrawMotion ", " FeedBack " and " StrokeWidth. >+These options are disabled by default. >+.I EchoSequence >+causes fvwm to Echo the recorded stroke sequence. >+.I DrawMotion >+causes fvwm to draw the mouse motion on the screen. >+.I FeedBack >+causes fvwm to display during a fraction of second the cursor of the >+.I WAIT >+context of the >+.B CursorStyle >+command if the recorded stroke sequence corresponds to a stroke >+binding. >+.I StrokeWidth >+takes an integer argument, which must be >= 0 and <= 100 and >+which defines the width of the line for the >+.I DrawMotion option. >+ >+.I NotStayPressed >+works only if >+.B StrokeFunc >+is used via a >+.BR Mouse >+or a >+.B Key >+command. This option removes the need to have a button or the key >+pressed during the stroke, but you have to do a mouse click or >+press the >+.SM Return >+or >+.SM Space >+key to finish the mouse motion recording (these keys also work >+without the >+.I NotStayPressed >+option). >+ >+You can use the >+.B StrokeFunc >+"alone". In this case it works as above with the >+.I NotStayPressed >+option enabled. However, >+.I Modifiers, >+in general, may not work as expected (i.e., in this case use 'A' >+or 'N' as >+.I Modifiers >+in the stroke bindings). >+ >+Note that some computers do not support key release events. If >+that is the case the >+.B StrokeFunc >+used via a >+.B Key >+command works as if the >+.I NotStayPressed >+option is enabled. >+ >+ >+.SS THE STYLE COMMAND (CONTROLLING WINDOW STYLES) >+ >+.TP >+.BI "UpdateStyles" >+All pending updates of all windows' styles and looks are applied >+immediately. E.g. if >+.BR Style " or " TitleStyle >+commands were issued inside a fvwm function. >+ >+.TP >+.BI "Style " "stylename options" >+This command is intended to replace the old fvwm 1.xx global >+commands NoBorder, NoTitle, StartsOnDesk, Sticky, StaysOnTop, >+Icon, WindowListSkip, CirculateSkip, SuppressIcons, BoundaryWidth, >+NoBoundaryWidth, StdForeColor, and StdBackColor with a single >+flexible and comprehensive window specific command. This command >+is used to set attributes of a window to values other than the >+default or to set the window manager default styles. >+ >+.I stylename >+can be a window's name, class, or resource string. It may contain >+the wildcards '*' and '?', which are matched in the usual Unix >+filename manner. They are searched in the reverse order >+stated. When two conflicting styles apply to the same window, the >+style that was changed last wins. >+ >+Note: windows that have no name (WM_NAME) are given a name of >+"Untitled", and windows that don't have a class (WM_CLASS, >+res_class) are given class "NoClass" and those that don't have a >+resource (WM_CLASS, res_name) are given resource "NoResource". >+ >+.I options >+is a comma separated list containing one or more of the keywords >+.IR BorderWidth ", " HandleWidth , >+.IR NoIcon " / " Icon ", " MiniIcon , >+.IR IconBox ", " IconGrid ", " IconFill , >+.IR NoTitle " / " Title , >+.IR TitleAtBottom " / " TitleAtTop , >+.IR StippledTitle " / " StippledTitleOff , >+.IR NoHandles " / " Handles , >+.IR WindowListSkip " / " WindowListHit , >+.IR CirculateSkip " / " CirculateHit , >+.IR CirculateSkipShaded " / " CirculateHitShaded , >+.IR Layer , >+.IR StaysOnTop " / " StaysOnBottom " / " StaysPut , >+.IR Sticky " / " Slippery , >+.IR StartIconic " / " StartNormal , >+.IR Color ", " ForeColor ", " BackColor ", " Colorset , >+.IR HilightFore ", " HilightBack ", " HilightColorset , >+.IR BorderColorset ", " HilightBorderColorset , >+.IR Font , >+.IR IconFont , >+.IR StartsOnDesk " / " StartsOnPage " / " StartsAnyWhere , >+.IR StartsOnScreen , >+.IR ManualPlacementHonorsStartsOnPage " / " ManualPlacementIgnoresStartsOnPage , >+.IR CaptureHonorsStartsOnPage " / " CaptureIgnoresStartsOnPage , >+.IR RecaptureHonorsStartsOnPage " / " RecaptureIgnoresStartsOnPage , >+.IR StartsOnPageIncludesTransients " / " StartsOnPageIgnoresTransients , >+.IR IconTitle " / " NoIconTitle , >+.IR MwmButtons " / " FvwmButtons , >+.IR MwmBorder " / " FvwmBorder , >+.IR MwmDecor " / " NoDecorHint , >+.IR MwmFunctions " / " NoFuncHint , >+.IR HintOverride " / " NoOverride , >+.IR NoButton " / " Button , >+.IR ResizeHintOverride " / " NoResizeOverride , >+.IR OLDecor " / " NoOLDecor , >+.IR GNOMEUseHints " / " GNOMEIgnoreHints , >+.IR StickyIcon " / " SlipperyIcon , >+.IR ManualPlacement " / " CascadePlacement " / " MinOverlapPlacement " / " >+.IR MinOverlapPercentPlacement " / " TileManualPlacement " / " >+.IR TileCascadePlacement , >+.IR DecorateTransient " / " NakedTransient , >+.IR RaiseTransient " / " DontRaiseTransient , >+.IR LowerTransient " / " DontLowerTransient , >+.IR StackTransientParent " / " DontStackTransientParent , >+.IR SkipMapping " / " ShowMapping , >+.IR ScatterWindowGroups " / " KeepWindowGroupsOnDesk , >+.IR UseDecor , >+.IR UseStyle , >+.IR NoPPosition " / " UsePPosition , >+.IR NoUSPosition " / " UseUSPosition , >+.IR NoTransientPPosition " / " UseTransientPPosition , >+.IR NoTransientUSPosition " / " UseTransientUSPosition , >+.IR UseIconPosition " / " NoIconPosition , >+.IR Lenience " / " NoLenience , >+.IR ClickToFocus " / " SloppyFocus " /" >+.IR MouseFocus | FocusFollowsMouse " / " NeverFocus , >+.IR ClickToFocusPassesClickOff " / " ClickToFocusPassesClick , >+.IR ClickToFocusRaisesOff " / " ClickToFocusRaises , >+.IR MouseFocusClickRaises " / " MouseFocusClickRaisesOff , >+.IR StartsLowered " / " StartsRaised , >+.IR GrabFocus " / " GrabFocusOff , >+.IR GrabFocusTransient " / " GrabFocusTransientOff , >+.IR IgnoreRestack " / " AllowRestack , >+.IR FixedPosition " / " VariablePosition , >+.IR IconOverride " / " NoIconOverride " / " NoActiveIconOverride , >+.IR DepressableBorder " / " FirmBorder , >+.IR MaxWindowSize , >+.IR IconifyWindowGroups " / " IconifyWindowGroupsOff , >+.IR ResizeOpaque " / " ResizeOutline , >+.IR BackingStore " / " BackingStoreOff , >+.IR Opacity " / " ParentalRelativity , >+.IR SaveUnder " / " SaveUnderOff , >+.IR WindowShadeShrinks " / " WindowShadeScrolls , >+.IR WindowShadeSteps. >+ >+.\" +++++++++++++++ general notes >+In the above list some options are listed as >+style-option/opposite-style-option. The opposite-style-option for >+entries that have them describes the fvwm default behavior and can >+be used if you want to change the fvwm default behavior. >+ >+.\" +++++++++++++++ focus policy >+.TP >+.B Focus policy >+.I ClickToFocus >+instructs fvwm to give the focus to the window when it is clicked >+in. The default >+.I MouseFocus >+(or its alias >+.IR FocusFollowsMouse ) >+tells fvwm to give the window the focus as soon as the pointer >+enters the window, and take it away when the pointer leaves the >+window. >+.I SloppyFocus >+is similar, but doesn't give up the focus if the pointer leaves >+the window to pass over the root window or a ClickToFocus window >+(unless you click on it, that is), which makes it possible to move >+the mouse out of the way without losing focus. A window with the >+style >+.I NeverFocus >+never receives the focus. This is useful for modules like >+.BR FvwmButtons , >+for example. >+ >+The focus model can be augmented with several additional options. >+.IR ClickToFocusPassesClickOff " and " ClickToFocusPassesClick >+controls if a mouse click to focus a window using the >+.I ClickToFocus >+model is sent to the application or not. Similarly, >+.IR ClickToFocusRaisesOff " and " ClickToFocusRaises >+control if the window is raised, while >+.IR MouseFocusClickRaises " and " MouseFocusClickRaisesOff >+are equivalent but apply only to windows using >+.IR SloppyFocus ", " MouseFocus " and " NeverFocus . >+The defaults are >+.IR ClickToFocusPassesClick , >+.IR ClickToFocusRaises " and " MouseFocusClickRaisesOff . >+ >+.I GrabFocus >+causes a newly mapped window to grab the focus, while >+.I GrabFocusOff >+turns this off. >+.I GrabFocus >+is the default for >+.I ClickToFocus >+windows and >+.I GrabFocusOff >+is the default for >+.IR MouseFocus " and " SloppyFocus >+windows. Note that this option is switched back to the default >+every time you change the focus policy. You have to use it after >+the initial >+.IR ClickToFocus / MouseFocus / SloppyFocus . >+This style does not apply to transient windows. The >+.IR GrabFocusTransient " and " GrabFocusTransientOff >+styles are responsible for this behavior. By default, >+.I GrabFocusTransient >+is turned on. >+ >+.I Lenience >+instructs fvwm to ignore the convention in the >+.SM ICCCM >+which states that if an application sets the input field of the >+wm_hints structure to False, then it never wants the window >+manager to give it the input focus. The only application that we >+know of which needs this is sxpm, and that is a silly bug with a >+trivial fix and has no overall effect on the program anyway. >+Rumor is that some older applications have problems too. >+ >+.\" +++++++++++++++ styles affecting the window title >+.TP >+.B Window title >+The >+.IR Title " and " NoTitle >+options determine if the window has a title-bar or not. By >+default all windows have a title-bar. >+ >+Windows with the >+.I TitleAtBottom >+style have a title-bar below the window instead of above as >+usual. The >+.I TitleAtTop >+style restores the default placement. Even if the window has the >+.I NoTitle >+style set, this affects the >+.I WindowShade >+command. >+ >+With the >+.I StippledTitle >+style, are drawn with the same effect that is usually reserved for >+windows with the >+.I Sticky >+style. >+.I StippledTitleOff >+reverts back to normal titles. >+ >+.I Color >+takes two arguments. The first is the window-label text color and >+the second is the window decoration's normal background color. The >+two colors are separated with a slash. If the use of a slash >+causes problems then the separate >+.IR ForeColor " and " BackColor >+options can be used. >+ >+.I Colorset >+takes the colorset number as its sole argument and overrides the >+colors set by >+.IR Color . >+Instead, the corresponding colors from the given colorset are >+used. Note that all other features of a colorset are unsupported >+yet. To stop using the colorset, the colorset number can be >+omitted. >+ >+The >+.IR HilightFore ", " HilightBack " and " HilightColorset >+style options work exactly like >+.IR ForeColor ", " BackColor " and " Colorset >+but are used only if the window has the focus. These styles >+replace the old commands >+.BR HilightColor " and " HilightColorset . >+ >+.IR BorderColorset >+takes the colorset number as its sole argument and overrides the >+colors set by >+.IR Color " or " Colorset . >+for the window border. To stop using a colorset, the argument can >+be omitted. >+ >+The >+.IR HilightBorderColorset >+style option works similarly to >+.IR BorderColorset >+but is used when the window has the focus. >+ >+The >+.IR Font " and " IconFont >+options take the name of a font as their sole argument. This font >+is used in the window or icon title. By default the font given in >+the >+.B DefaultFont >+command is used. To revert back to the default, use the style >+without the name argument. These styles replace the older >+.BR WindowFont " and " IconFont >+commands. >+ >+.\" +++++++++++++++ styles affecting title buttons >+.TP >+.B Title buttons >+.IR Button " and " NoButton >+take a numeric argument which is the number of the title-bar >+button which is to be included/omitted. >+ >+.I MwmButtons >+makes the >+.B Maximize >+button look pressed-in when the window is maximized. See the >+.I MwmDecorMax >+flag in >+.B ButtonStyle >+for more information. To switch this style off again, use the >+.I FvwmButtons >+style. >+ >+.\" +++++++++++++++ styles affecting borders >+.TP >+.B Borders >+.I MwmBorder >+makes the 3-D bevel more closely match Mwm's. >+.I FvwmBorder >+turns off the previous option. >+ >+.I HandleWidth >+takes a numeric argument which is the width of the border to place >+the window if it does have resize-handles. >+ >+.I BorderWidth >+takes a numeric argument which is the width of the border to place >+the window if it does not have resize-handles. >+ >+.I DepressableBorder >+makes the border parts of the window decoration look sunken in >+when a button is pressed over them. This can be disabled again >+with the >+.I FirmBorder >+style. >+ >+.\" +++++++++++++++ icons, shading, maximizing, movement, resizing >+.TP >+.B Icons, shading, maximizing, movement, resizing >+.I Icon >+takes an (optional) unquoted string argument which is the icon >+bitmap or pixmap to use. Icons specified this way override pixmap >+icons, but not icon windows, provided by the client in the >+application (with the WM_HINTS property). The >+.I IconOverride >+style changes the behavior to override any client-provided icons; >+the >+.I NoIconOverride >+style changes the behavior to not override any client-provided >+icons; the default overriding behavior can be activated with the >+.I NoActiveIconOverride >+style. With this style, fvwm uses application provided icons if >+the icon is changed but uses the icon provided in the >+configuration file until then. >+ >+There is one exception to these rules, namely >+.EX >+Style * Icon unknown.xpm >+.EE >+doesn't force the unknown.xpm icon on every window, it just sets >+the default icon like the DefaultIcon command. If you really want >+all windows to have the same icon, you can use >+.EX >+Style ** Icon unknown.xpm >+.EE >+If the >+.I NoIcon >+attribute is set then the specified window simply disappears when >+it is iconified. The window can be recovered through the >+window-list. If >+.I Icon >+is set without an argument then the >+.I NoIcon >+attribute is cleared but no icon is specified. An example which >+allows only the >+.B FvwmPager >+module icon to exist: >+.EX >+Style * NoIcon >+Style FvwmPager Icon >+.EE >+ >+.I IconBox >+takes no argument, four numeric arguments (plus optionally a >+screen specification), an X11 geometry string or the string >+"none": >+.EX >+.RI IconBox " [" "screen scr-spec" "] " "l t r b" >+.EE >+or >+.EX >+IconBox geometry >+.EE >+Where >+.I l >+is the left coordinate, >+.I t >+is the top, >+.I r >+is right and >+.I b >+is bottom. Negative coordinates indicate distance from the right >+or bottom of the screen. >+If the first argument is the word >+.IR screen , >+the >+.I scr-spec >+argument specifies the Xinerama screen on which the IconBox is >+defined. It can be the usual screen Xinerama specification, 'p', >+'c', 'g', a screen number or the additional 'w' for the screen >+where the window center is located. This is only useful with >+multiple Xinerama screens. Perhaps easier to use is an X11 >+geometry string: >+.EX >+IconBox -80x200-1-1 >+.EE >+Which would place an 80 by 240 pixel icon box in the lower right >+hand corner of the screen. The icon box is a region of the screen >+where fvwm attempts to put icons for any matching window, as long >+as they do not overlap other icons. Multiple icon boxes can be >+defined as overflow areas. When the first icon box is full, the >+second one is filled. All the icon boxes for one style must be >+defined in one >+.B Style >+command. For example: >+.EX >+Style * IconBox -80x200-1-1, \\ >+ IconBox 1000x70-1-1 >+.EE >+A Style command with the IconBox option replaces any icon box >+previously defined for the same style. Thats why the backslash in >+the previous example is required. >+ >+Note: The geometry for the icon box command takes the additional >+screen specifier "@w" in case a Xinerama setup is used. This >+designates the screen where the window center is located. The >+additional screen specifier is not allowed anywhere else. >+ >+If you never define an icon box, or you fill all the icon boxes, >+fvwm has a default icon box that covers the screen, it fills top >+to bottom, then left to right, and has an 80x80 pixel grid. To >+disable all but the default icon box you can use IconBox without >+arguments in a separate >+.B Style >+command. To disable all icon boxes including the default icon >+box, the argument "none" can be specified. >+ >+Hint: You can auto arrange your icons in the icon box with a >+simple fvwm function. Put the "DeiconifyAndRearrange" function >+below in your configuration file: >+.EX >+AddToFunc DeiconifyAndRearrange >+ + C Iconify off >+ + C All (CurrentPage Iconic) RecaptureWindow >+.EE >+And then replace all places where you call the >+.B Iconify >+builtin function to de-iconify an icon with a call to the new >+function. For example replace >+.EX >+AddToFunc IconFunc >+ + C Iconify off >+ + M Raise >+ + M Move >+ + D Iconify off >+ >+Mouse 1 I A Iconify off >+.EE >+with >+.EX >+AddToFunc IconFunc >+ + C DeiconifyAndRearrange >+ + M Raise >+ + M Move >+ + D DeiconifyAndRearrange >+ >+Mouse 1 I A DeiconifyAndRearrange >+.EE >+.I IconGrid >+takes 2 numeric arguments greater than zero. >+.EX >+.I IconGrid x y >+.EE >+Icons are placed in an icon box by stepping through the icon box >+using the >+.IR x " and " y >+values for the icon grid, looking for a free space. The default >+grid is 3 by 3 pixels which gives a tightly packed appearance. To >+get a more regular appearance use a grid larger than your largest >+icon. Currently there is no way to clip an icon to a maximum >+size. An >+.I IconGrid >+definition must follow the >+.B IconBox >+definition that it applies to: >+.EX >+Style * IconBox -80x240-1-1, IconGrid 90 90 >+.EE >+.I IconFill >+takes 2 arguments. >+.EX >+.RI "IconFill " "Bottom Right" >+.EE >+Icons are placed in an icon box by stepping through the icon box >+using these arguments to control the direction the box is filled >+in. By default the direction is left to right, then top to bottom. >+This would be expressed as: >+.EX >+IconFill left top >+.EE >+To fill an icon box in columns instead of rows, specify the >+vertical direction (top or bottom) first. The directions can be >+abbreviated or spelled out as follows: "t", "top", "b", "bot", >+"bottom", "l", "lft", "left", "r", "rgt", "right". An >+.B IconFill >+definition must follow the >+.B IconBox >+definition that it applies to: >+.EX >+Style * IconBox -80x240-1-1, IconFill b r >+.EE >+.I MiniIcon >+specifies a pixmap to use as the miniature icon for the >+window. This miniature icon can be drawn in a title-bar button >+(see >+.BR ButtonStyle ), >+and can be used by various fvwm modules >+.RB ( FvwmWinList ", " FvwmIconMan " and " FvwmTaskBar ). >+It takes the name of a pixmap as an argument. >+ >+.I WindowShadeShrinks " and " WindowShadeScrolls >+control if the contents of a window that is being shaded with the >+.B WindowShade >+command are scrolled (default) or if they stay in place. >+ >+The >+.I WindowShadeSteps >+option selects the number of steps for animation when shading a >+window with >+.BR WindowShade . >+It takes one number as its argument. If the number has a trailing >+.RI ' p ' >+it sets the number of pixels to use as the step size instead of >+a fixed number of steps. 0 disables the animation. This happens >+too if the argument is omitted or invalid. >+ >+.I ResizeOpaque >+instructs fvwm to resize the corresponding windows with their >+contents visible instead of using an outline. Since this causes >+the application to redraw frequently it can be quite slow and make >+the window flicker excessively, depending on the amount of >+graphics the application redraws. The >+.I ResizeOutline >+style (default) negates the >+.I ResizeOpaque >+style. Many applications do not like their windows being resized >+opaque, e.g. XEmacs, Netscape or terminals with a pixmap >+background. If you do not like the result, don't use the >+.I ResizeOpaque >+style for these windows. To exempt certain windows from opaque >+resizing you could use these lines in your configuration file: >+.EX >+Style * ResizeOpaque >+Style rxvt ResizeOutline >+Style emacs ResizeOutline >+.EE >+.I Sticky >+makes the window sticky, i.e. it is always visible on each page >+and each desk. The opposite style, >+.I Slippery >+reverts back to the default. >+ >+.I StickyIcon >+makes the window sticky when its iconified. It de-iconifies on >+top the active desktop. >+.I SlipperIcon >+reverts back to the default. >+ >+.I IgnoreRestack >+makes fvwm ignore attempts of clients to raise or lower their own >+windows. By default, the opposite style, >+.I AllowRestack >+is active. >+ >+.I FixedPosition >+makes fvwm ignore attempts of the user to move the window. To >+allow user movement of windows, use the >+.I VariablePosition >+style. >+ >+.I ResizeHintOverride >+instructs fvwm to ignore the program supplied minimum and maximum >+size. This can be handy for broken applications that refuse to be >+resized. Don't use it if you don't need it. The default >+(opposite) style is >+.I NoResizeOverride. >+ >+.I MaxWindowSize " [ width [ p ] height [ p ] ]" >+Tells fvwm the maximum width and height of a window. The values >+are the percentage of the total screen area. If the letter >+.RI ' p ' >+is appended to either of the values, the numbers are interpreted >+as pixels. This command is useful to force large application >+windows to be fully visible. Neither >+.IR height " or " width >+may be less than 100 pixels. If you omit the parameters or their >+values are invalid, both limits are set to 32767 pixels (which is >+the default). >+ >+With >+.I IconifyWindowGroups >+all windows in the same window group are iconified at once when >+group leader is iconified. The default is >+.IR IconifyWindowGroupsOff , >+which disables this behaviour. Although a number of applications >+use the window group hint, it is rarely used in a proper way, so >+it is probably best to use >+.I IconifyWindowGroups >+only for selected applications. >+ >+.\" +++++++++++++++ Window Manager placement >+.TP >+.B Window Manager placement >+Applications can place windows at a particular spot on the screen >+either by window manager hints or a geometry specification. When >+they do neither, then the window manager steps in to find a place >+for the window. Fvwm knows six ways to deal with this >+situation. The default is >+.IR TileCascadePlacement . >+ >+.I CascadePlacement >+automatically place new windows in a cascading fashion. >+ >+.I TileCascadePlacement >+automatically places new windows in a smart location - a location >+in which they do not overlap any other windows on the screen. If >+no such position can be found >+.IR CascadePlacement >+is used as a fall-back method. >+ >+.I TileManualPlacement >+This is the same as >+.IR TileCascadePlacement , >+but uses >+.IR ManualPlacement >+as the fall-back method. >+ >+.I MinOverlapPlacement >+automatically places new windows in a location in which the >+overlapping area in pixels of other windows is minimal. This >+placement policy especially tries to avoid overlapping icons and >+windows on higher layers. >+ >+.I MinOverlapPercentPlacement >+is similar to >+.IR MinOverlapPlacement >+but tries to minimize the overlapped percentages of other windows >+instead of the overlapped area in pixels. This placement policy >+tries to avoid covering other windows completely and tries even >+harder not to cover small windows. >+ >+.I ManualPlacement >+(aka active placement). The user is required to place every new >+window manually. The window only shows as a rubber band until a >+place is selected manually. The window is placed when a mouse >+button or any key except >+.SM Escape >+is pressed. Escape aborts manual placement which places the >+window in the top left corner of the screen. If mouse button 2 is >+pressed during the initial placement of a window (respectively >+.SM Shift >+and mouse button 1 in case Mwm emulation has been enabled with the >+.B Emulate >+command), the user is asked to resize the window too. Pressing >+button 3 sets the >+.I PlacedByButton3 >+condition (see >+.B Current >+command). >+ >+Example: >+.EX >+Style * ManualPlacement >+ >+*FvwmEvent: PassID >+*FvwmEvent: add_window GrowDownFunc >+AddToFunc StartFunction >++ I FvwmEvent >+ >+AddToFunc GrowDownFunc >++ I windowid $0 (PlacedByButton3) \\ >+ Resize bottomright keep -0p >+.EE >+ >+Now, whenever a window is created and the user presses button 3 to >+finish initial placement, the window is automatically enlarged >+until it hits the bottom screen border. >+ >+.I Old placement styles >+DumbPlacement / SmartPlacement / SmartPlacementOff, >+ActivePlacement / RandomPlacement, >+ActivePlacementsHonorsStartsOnPage / ActivePlacementsHonorsStartsOnPageOff, >+GlobalOpts SmartPlacementIsReallySmart / GlobalOpts SmartPlacementIsNormal >+are still supported but will be removed in the future. The old and >+new styles can be translated according to the following table: >+.EX >+GlobalOpts SmartPlacementIsReallySmart >+Style * SmartPlacement >+ --> >+Style * SmartPlacement, CleverPlacement >+ >+Global SmartPlacementIsNormal >+Style * SmartPlacement >+ --> >+Style * SmartPlacement, CleverPlacementOff >+ >+Style * DumbPlacement, RandomPlacement >+ --> >+Style * CascadePlacement >+ >+Style * DumbPlacement, ActivePlacement >+ --> >+Style * ManualPlacement >+ >+Style * SmartPlacement + RandomPlacement + CleverPlacementOff >+ --> >+Style * TileCascadePlacement >+ >+Style * SmartPlacement + ActivePlacement + CleverPlacementOff >+ --> >+Style * TileManualPlacement >+ >+Style * SmartPlacement + CleverPlacement >+ --> >+Style * MinOverlapPlacement >+ >+Style * SmartPlacement, ActivePlacement, CleverPlacement >+ --> >+Style * MinOverlapPercentPlacement >+ >+Style * ActivePlacementsHonorsStartsOnPage >+ --> >+Style * ManualPlacementsHonorsStartsOnPage >+ >+Style * ActivePlacementsHonorsStartsOnPageOff >+ --> >+Style * ManualPlacementsHonorsStartsOnPageOff >+.EE >+ >+.\" +++++++++++++++ placement options and stacking policy >+.TP >+.B Placement policy options and window stacking >+.I NoPPosition >+instructs fvwm to ignore the program specified position (PPosition >+hint) when adding new windows. Using PPosition is required for >+some applications, but if you don't have one of those its a real >+headache. Many programs set PPosition to something obnoxious like >+0,0 (upper left corner). >+ >+.I NoUSPosition >+works like >+.I NoPPosition >+but applies suppresses using the user specified position indicated >+by the program (USPosition hint). It is generally a bad thing to >+override the user's choice, but some applications misuse the >+USPosition hint to force their windows to a certain spot on the >+screen without the user's consent. >+ >+.IR NoTransientPPosition " and " UseTransientPPosition >+work like >+.IR NoPPosition " and " UsePPosition >+but apply only to transient windows. >+ >+.I NoIconPosition >+instructs fvwm to ignore the program specified icon position >+(IconPosition hint) when iconifying the window. >+ >+.I StartsOnDesk >+takes a numeric argument which is the desktop number on which the >+window should be initially placed. Note that standard Xt programs >+can also specify this via a resource (e.g. "-xrm '*Desk: 1'"). >+ >+.I StartsOnPage >+takes 1, 2, or 3 numeric arguments. If one or three arguments are >+given, the first (or only) argument is the desktop number. If >+three arguments are given, the 2nd and 3rd arguments identify the >+x,y page position on the virtual window. If two arguments are >+given, they specify the page position, and indicate no desk >+preference. If only one argument is given, >+.I StartsOnPage >+functions exactly like >+.IR StartsOnDesk . >+For those standard Xt programs which understand this usage, the >+starting desk/page can also be specified via a resource (e.g., >+"-xrm '*page: 1 0 2'"). >+.I StartsOnPage >+in conjunction with >+.I SkipMapping >+is a useful technique when you want to start an app on some other >+page and continue with what you were doing, rather than waiting >+for it to appear. >+ >+.I StartsOnScreen >+takes one argument. It can be 'p' for the primary screen, 'c' for >+the current screen (containing the mouse pointer), 'g' for the >+global screen or the screen number itself (counting from zero). >+A new window is placed on the specified Xinerama screen. The >+default is to place windows on the screen that contains the mouse >+pointer at the time the window is created. >+However, those windows which are not placed by FVWM (i.e., those with >+a USPosition hint from a user specified geometry) are normally placed >+in a position relative to the global screen. The >+.I StartsOnScreen >+style is also useful to cause these windows to be placed relative >+to a specific Xinerama screen. For example: >+.EX >+Style * StartsOnScreen c >+.EE >+Would cause all windows, including those with their own geometry >+to be placed relative to the current Xinerama screen rather than >+the global screen. >+For those standard Xt programs which understand this usage, the >+starting desk/page can also be specified via a resource (e.g., >+"-xrm '*fvwmscreen: c'"). ('fvwmscreen' was chosen >+because some applications already use '.screen' for other >+purposes.) >+ >+.I StartsOnPageIncludesTransients >+causes the >+.I StartsOnPage >+style to be applied even for transient windows. This is not >+usually useful, since transients are usually pop ups that you want >+to appear in your visible viewport; but occasionally an >+application uses a transient for something like a startup window >+that needs to be coerced into place. >+ >+.I ManualPlacementIgnoresStartsOnPage >+suppresses >+.IR StartsOnPage " or " StartsOnDesk >+placement in the event that both >+.IR ManualPlacement " and " SkipMapping >+are in effect when a window is created. This prevents you from >+interactively placing a window and then wondering where it >+disappeared to, because it got placed on a different desk or page. >+.I ManualPlacementHonorsStartsOnPage >+allows this to happen anyway. The option has no effect if >+.I SkipMapping >+is not in effect, because fvwm switches to the proper desk/page to >+perform interactive placement. The default is >+.IR ManualPlacementIgnoresStartsOnPage "; " >+.I ManualPlacementHonorsStartsOnPage >+matches the way the old >+.I StartsOnDesk >+style used to handle the situation. >+ >+.I CaptureHonorsStartsOnPage >+causes the initial capture (of an already existing window) at >+startup to place the window according to the >+.IR StartsOnPage " and " StartsOnScreen >+desk, page and Xinerama screen specification. >+.I CaptureIgnoresStartsOnPage >+causes fvwm to ignore these settings (including >+.IR StartsOnDesk ) >+on initial capture. The default is >+.IR CaptureIgnoresStartsOnPage . >+ >+.I RecaptureHonorsStartsOnPage >+causes a window to be placed according to, or revert to, the >+.IR StartsOnPage " and " StartsOnScreen >+desk, page and Xinerama screen specification on >+.BR Restart " or " Recapture . >+.I RecaptureIgnoresStartsOnPage >+causes fvwm to respect the current window position on >+.BR Restart " or " Recapture . >+The default is >+.IR RecaptureIgnoresStartsOnPage . >+ >+.I Layer >+accepts one optional argument: a non-negative integer. This is >+the layer the window is put in. If no argument is given, any >+previously set value is deleted and the default layer is implied. >+ >+.I StaysOnTop >+puts the window in the top layer. This layer can be changed by >+the built-in command >+.BR DefaultLayers ; >+the default is 6. >+ >+.I StaysPut >+puts the window in the put layer. This layer can be changed by >+the built-in command >+.BR DefaultLayers ; >+the default is 4. >+ >+.I StaysOnBottom >+puts the window in the bottom layer. This layer can be changed by >+the built-in command >+.BR DefaultLayers ; >+the default is 2. >+ >+.I StartsLowered >+instructs fvwm to put the window initially at the bottom of its >+layer rather than the default >+.IR StartsRaised . >+ >+.I SkipMapping >+tells fvwm not to switch to the desk the window is on when it gets >+mapped initially (useful with >+.IR StartsOnDesk " or " StartsOnPage ). >+ >+.I KeepWindowGroupsOnDesk >+makes new windows that have the window group hint set appear on >+the same desk as the other windows of the same group. Since this >+bevhaviour may be confusing, the default setting is >+.IR ScatterWindowGroups . >+The window group hint is ignored when placing windows in this >+case. >+ >+.\" +++++++++++++++ transient windows >+.TP >+.B Transient windows >+.I DecorateTransient >+causes transient windows, which are normally left undecorated, to >+be given the usual fvwm decorations (title bar, buttons, >+etc.). Note that some pop-up windows, such as the xterm menus, are >+not managed by the window manager and still do not receive >+decorations. >+.I NakedTransient >+(the default) causes transient windows not to be given the >+standard decorations. You can only bind keys or mouse buttons to >+the sides and the client window of an undecorated window ('S' >+and 'W' contexts in bindings, see >+.BR Mouse " and " Key >+commands). >+ >+A window with the >+.I RaiseTransient >+style that has transient windows raises all its transients when it >+is raised. The >+.I DontRaiseTransient >+style disables this behavior. All windows are then treated as if >+they had no transients. >+ >+A window with the >+.I LowerTransient >+style that has transient windows lowers all its transients when it >+is lowered. The >+.I DontLowerTransient >+style disables this behavior. All windows are then treated as if >+they had no transients. >+ >+The >+.I StackTransientParent >+style augments >+.IR RaiseTransient " and " LowerTransient >+styles. Raising a window with >+.I StackTransientParent >+style transfers the raise action to the main window if the window >+being raised is a transient and its main window has >+.I RaiseTransient >+style; this effect makes raise on a transient act just like raise >+on its main - the whole group is raised. Similar behavior holds >+for lowering a whole group of transients when the main has >+.I LowerTransient >+style. >+.I DontStackTransientParent >+turns this behavior off. >+.I (Dont)StackTransientParent >+has no effect if >+.IR RaiseTransient " and " LowerTransient >+are not used. >+ >+A reasonable emulation of Motif raise/lower on transients is >+possible like this >+.EX >+Style * RaiseTransient >+Style * LowerTransient >+Style * StackTransientParent >+.EE >+ >+.\" +++++++++++++++ miscellaneous >+.TP >+.B Miscellaneous >+The >+.IR BackingStore " and " SaveUnder >+styles enable the corresponding window attributes in the X server. >+.I BackingStore >+means that the X server tries to keep the obscured parts of a >+window in memory while windows with >+.I SaveUnder >+store the graphics below them. Either option can speed up fvwm if >+the connection to the X server is slow (e.g. over a modem link). >+By default both styles are turned off. To switch them off >+explicitly you can use the >+.IR BackingStoreOff " and " SaveUnderOff >+styles. >+ >+.I ParentalRelativity >+enables clients that use a background pixmap of type >+.IR ParentRelative >+to achieve transparency. Fvwm modules that support transparent >+colorsets require this setting. >+.I Opacity >+is the default and should be used for all non-transparent clients >+for better performance. >+ >+.I MwmDecor >+makes fvwm attempt to recognize and respect the mwm decoration >+hints that applications occasionally use. To switch this style >+off, use the >+.I NoDecorHint >+style. >+ >+.I MwmFunctions >+makes fvwm attempt to recognize and respect the mwm prohibited >+operations hints that applications occasionally use. >+.I HintOverride >+makes fvwm shade out operations that mwm would prohibit, but it >+lets you perform the operation anyway. >+.I NoFuncHint >+allows turns off the mwm hints completely. >+ >+.I OLDecor >+makes fvwm attempt to recognize and respect the olwm and olvwm >+hints that many older XView and OLIT applications use. Switch >+this option off with >+.IR NoOLDecor . >+ >+With >+.I GNOMEIgnoreHints >+fvwm ignores all GNOME hints for the window, even if GNOME >+compliance is compiled in. This is useful for those pesky >+applications that try to be more clever than the user and use >+GNOME hints to force the window manager to ignore the user's >+preferences. The >+.I GNOMEUseHints >+style switches back to the default behaviour. >+ >+.I UseDecor >+accepts one argument: the name of a decor created with >+.BR AddToDecor . >+If no decor name is specified, the "Default" decor is >+used. Windows do not actually contain decors, but are always >+assigned to one. If the decor is later modified with >+.BR AddToDecor , >+the changes are visible for all windows which are assigned to it. >+The decor for a window can be reassigned with >+.BR ChangeDecor . >+ >+.I UseStyle >+takes one arg, which is the name of another style. That way you >+can have unrelated window names easily inherit similar traits >+without retyping. For example: >+.EX >+ Style rxvt UseStyle XTerm >+.EE >+Warning: If a style is built from one or more parent styles and >+the parent styles are changed, the derived style is not >+modified. To achieve this you have to issue the >+.I UseStyle >+line again. >+ >+.\" +++++++++++++++ examples >+.TP >+.B Examples >+.EX >+# Change default fvwm behavior to no title- >+# bars on windows! Also define a default icon. >+Style * NoTitle, \\ >+ Icon unknown1.xpm, \\ >+ BorderWidth 4, \\ >+ HandleWidth 5 >+ >+# now, window specific changes: >+Style Fvwm* NoHandles, Sticky, \\ >+ WindowListSkip, \\ >+ BorderWidth 0 >+Style FvwmPager StaysOnTop, BorderWidth 0 >+Style *lock NoHandles, Sticky, \\ >+ StaysOnTop, WindowListSkip >+Style xbiff Sticky, WindowListSkip >+Style FvwmButtons NoHandles, Sticky, \\ >+ WindowListSkip >+Style sxpm NoHandles >+ >+# Put title-bars back on xterms only! >+Style xterm Title, Color black/grey >+ >+Style rxvt Icon term.xpm >+Style xterm Icon rterm.xpm >+Style xcalc Icon xcalc.xpm >+Style xbiff Icon mail1.xpm >+Style xmh Icon mail1.xpm, \\ >+ StartsOnDesk 2 >+Style xman Icon xman.xpm >+Style matlab Icon math4.xpm, \\ >+ StartsOnDesk 3 >+Style xmag Icon magnifying_glass2.xpm >+Style xgraph Icon graphs.xpm >+Style FvwmButtons Icon toolbox.xpm >+Style Maker StartsOnDesk 1 >+Style signal StartsOnDesk 3 >+ >+# Fire up Netscape on the second desk, in the >+# middle of my 3x3 virtual desktop, and don't >+# bother me with it... >+Style Netscape* SkipMapping, \\ >+ StartsOnPage 1 1 1 >+.EE >+Note that all properties for a window are or'ed together. In the >+above example "FvwmPager" gets the property >+.I StaysOnTop >+via an exact window name match but also gets >+.IR NoHandles ", " Sticky " and " WindowListSkip >+by a match to "Fvwm*". It gets >+.I NoTitle >+by virtue of a match to "*". If conflicting styles are specified >+for a window, then the last style specified are used. >+ >+If the >+.I NoIcon >+attribute is set then the specified window simply disappears when >+it is iconified. The window can be recovered through the >+window-list. If >+.I Icon >+is set without an argument then the >+.I NoIcon >+attribute is cleared but no icon is specified. An example which >+allows only the FvwmPager module icon to exist: >+.EX >+Style * NoIcon >+Style FvwmPager Icon >+.EE >+ >+.TP >+.BI "DestroyStyle " style >+Deletes the style named >+.IR style . >+The changes take effect immediately. Note that >+.I style >+is not a wild-carded search string, but rather a case-sensitive >+string that should exactly match the original >+.B Style >+command. >+ >+Destroying style "*" can be done, but isn't really to be >+recommended. For example: >+.EX >+DestroyStyle Application* >+.EE >+This removes all settings for the style named "Application*", NOT >+all styles starting with "Application". >+ >+.SS OTHER COMMANDS CONTROLLING WINDOW STYLES >+ >+.IP "\fBAddButtonStyle\fP \fIbutton\fP \ >+\fB[\fP \fIstate\fP \ >+\fB] [\fP \fIstyle\fP \ >+\fB] [-- [!]\fP \fIflag\fP \ >+\fB...]\fP" >+ >+Adds a button style to >+.IR button . >+.I button >+can be a button number, or one of "All", "Left" or "Right". >+.I state >+can be "ActiveUp," "ActiveDown" or "Inactive" or any of these >+three with "Toggled" prepended. "ActiveUp" selects the style of >+the button when the window has the focus and the button is not >+pressed. "ActiveDown" is similar but applies when the button is >+pressed while the "Inactive" style is used for windows without the >+focus. The "Toggled" prefix refers to maximized, shaded or sticky >+windows that have the corresponding >+.I MwmDecor... >+button style set. If >+.I state >+is omitted, then the style is added to every state. If the >+.IR style " and " flags >+are enclosed in parentheses, then multiple >+.I state >+definitions can be placed on a single line. >+.I Flags >+for additional button styles cannot be changed after definition. >+ >+Buttons are drawn in the order of definition, beginning with the >+most recent button style, followed by those added with >+.BR AddButtonStyle . >+To clear the button style stack, change style flags, or for >+descriptions of available styles and flags, see the >+.B ButtonStyle >+command. Examples: >+.EX >+ButtonStyle 1 Pixmap led.xpm -- Top Left >+ButtonStyle 1 ActiveDown HGradient 8 grey \\ >+ black >+ButtonStyle All -- UseTitleStyle >+AddButtonStyle 1 ActiveUp (Pixmap a.xpm) \\ >+ ActiveDown (Pixmap b.xpm -- Top) >+AddButtonStyle 1 Vector 4 50x30@1 70x70@0 \\ >+ 30x70@0 50x30@1 >+.EE >+Initially for this example all button states are set to a pixmap. >+The second line replaces the "ActiveDown" state with a gradient >+(it overrides the pixmap assigned to it in the line before, which >+assigned the same style to every state). Then, the >+.I UseTitleStyle >+flag is set for all buttons, which causes fvwm to draw any styles >+set with >+.B TitleStyle >+before drawing the buttons. Finally, >+.B AddButtonStyle >+is used to place additional pixmaps for both "ActiveUp" and >+"ActiveDown" states and a vector button style is drawn on top of >+all state. >+ >+.IP "\fBAddTitleStyle [\fP \fIstate\fP \ >+\fB] [\fP \fIstyle\fP \ >+\fB] [-- [!]\fP \fIflag\fP \ >+\fB...]\fP" >+Adds a title style to the title-bar. >+.I state >+can be one of "ActiveUp," "ActiveDown" or "Inactive" or any of >+these with "Toggled" prepended. If >+.I state >+is omitted, then the style is added to every state. If the >+.IR style " and " flags >+are enclosed in parentheses, then multiple >+.I state >+definitions can be placed on a single line. This command is quite >+similar to the >+.B AddButtonStyle >+command (see above). >+ >+Title-bars are drawn in the order of definition, beginning with >+the most recent >+.BR TitleStyle , >+followed by those added with >+.BR AddTitleStyle . >+To clear the title style stack, change style flags, or for the >+descriptions of available styles and flags, see the >+.BR TitleStyle " and " ButtonStyle >+commands. >+ >+.TP >+.BI "AddToDecor " decor >+Add or divert commands to the decor named >+.IR decor . >+A decor is a name given to the set of commands which affect button >+styles, title-bar styles and border styles. If >+.I decor >+does not exist it is created; otherwise the existing >+.I decor >+is modified. Note: Earlier versions allowed to use the >+.BR HilightColor ", " HilightColorset " and " WindowFont >+commands in decors. This is no longer possible. Please use the >+.I Style >+command with the >+.IR Hilight... " and " Font >+options. >+ >+New decors start out exactly like the "default" decor without any >+style definitions. A given decor may be applied to a set of >+windows with the >+.I UseDecor >+option of the >+.B Style >+command. Modifying an existing decor affects all windows which >+are currently assigned to it. >+ >+.B AddToDecor >+is similar in usage to the >+.BR AddToMenu " and " AddToFunc >+commands, except that menus and functions are replaced by >+.BR ButtonStyle ", " AddButtonStyle ", " TitleStyle , >+.BR AddTitleStyle " and " BorderStyle >+commands. Decors created with >+.B AddToDecor >+can be manipulated with >+.BR ChangeDecor ", " DestroyDecor ", " UpdateDecor >+and the >+.IB "UseDecor " Style >+option. >+ >+The following example creates a decor "FlatDecor" and style >+"FlatStyle". They are distinct entities: >+.EX >+AddToDecor FlatDecor >+ + ButtonStyle All ActiveUp (-- flat) \\ >+ Inactive (-- flat) >+ + TitleStyle -- flat >+ + BorderStyle -- HiddenHandles NoInset >+ >+Style FlatStyle UseDecor FlatDecor, \\ >+ Color white/grey40,HandleWidth 4 >+ >+Style xterm UseStyle FlatStyle >+.EE >+An existing window's decor may be reassigned with >+.BR ChangeDecor . >+A decor can be destroyed with >+.BR DestroyDecor . >+.EX >+DestroyDecor FlatDecor >+AddToDecor FlatDecor ... >+ >+Style FlatStyle UseDecor FlatDecor, \\ >+ Color white/grey40,HandleWidth 4 >+.EE >+and now apply the style again: >+.EX >+Style xterm UseStyle FlatStyle >+.EE >+ >+.IP "\fBBorderStyle [\fP \fIstate\fP \ >+\fB] [\fP \fIstyle\fP \ >+\fB] [-- [!]\fP \fIflag\fP \ >+\fB...]\fP" >+Defines a border style for windows. >+.I state >+can be either "Active" or "Inactive". If >+.I state >+is omitted, then the style is set for both states. If the >+.IR style " and " flags >+are enclosed in parentheses, then multiple >+.I state >+definitions can be specified per line. >+ >+.I style >+is a subset of the available button styles, and can only be >+.I TiledPixmap >+(uniform pixmaps which match the bevel colors work best this >+way). If a >+.RI ' ! ' >+is prefixed to any >+.IR flag , >+the behavior is negated. If >+.I style >+is not specified, then one can change flags without resetting the >+style. >+ >+The >+.I HiddenHandles >+flag hides the corner handle dividing lines on windows with >+handles (this option has no effect for NoHandle windows). By >+default, >+.I HiddenHandles >+is disabled. >+ >+The >+.I NoInset >+flag supplements >+.IR HiddenHandles . >+If given, the inner bevel around the window frame is not drawn. >+If >+.I HiddenHandles >+is not specified, the frame looks a little strange. >+ >+.I Raised >+causes a raised relief pattern to be drawn (default). >+.I Sunk >+causes a sunken relief pattern to be drawn. >+.I Flat >+inhibits the relief pattern from being drawn. >+ >+To decorate the active and inactive window borders with a textured >+pixmap, one might specify: >+.EX >+BorderStyle Active TiledPixmap marble.xpm >+BorderStyle Inactive TiledPixmap granite.xpm >+BorderStyle Active -- HiddenHandles NoInset >+.EE >+To clear the style for both states: >+.EX >+BorderStyle Simple >+.EE >+To clear for a single state: >+.EX >+BorderStyle Active Simple >+.EE >+To unset a flag for a given state: >+.EX >+BorderStyle Inactive -- !NoInset >+.EE >+title-bar buttons can inherit the border style with the >+.I UseBorderStyle >+flag (see >+.BR ButtonStyle ). >+ >+.TP >+.BI "ButtonState [" "ActiveDown bool" "] [" "inactive bool" "]" >+The >+.B ButtonState >+command controls which states of the window titles and title >+buttons are used. The default is to use all three states: >+"ActiveUp", "ActiveDown" and "Inactive" (see >+.BR ButtonStyle " and " TitleStyle >+commands). The >+.I bool >+argument after the key word controls if the designated state is >+used ("True") or not ("False"). The "ActiveUp" state cannot be >+deactivated. If no arguments are provided or the given arguments >+are illegal, the default is restored. >+ >+The "ActiveDown" state allows different button styles for pressed >+down buttons and titles on active windows. Otherwise the >+"ActiveUp" state is used instead. The "Inactive" state allows >+different button and title styles for inactive windows. Otherwise >+the "ActiveUp" state is used instead. >+ >+.IP "\fBButtonStyle\fP \fIbutton\fP \ >+\fB[\fP \fIstate\fP \ >+\fB] [\fP \fIstyle\fP \ >+\fB] [-- [!]\fP \fIflag\fP \ >+\fB...]\fP" >+Sets the button style for a title-bar button. >+.I button >+is the title-bar button number between 0 and 9, or one of "All", >+"Left", "Right", or "Reset". Button numbering is described in the >+.B Mouse >+command section. If the >+.IR style " and " flags >+are enclosed in parentheses, then multiple >+.I state >+definitions can be specified per line. >+ >+.I state >+refers to which button state should be set. Button states are >+defined as follows: "ActiveUp" and "ActiveDown" refer to the >+un-pressed and pressed states for buttons on active windows; while >+the "Inactive" state denotes buttons on inactive windows. The >+"ToggledActiveUp", "ToggledActiveDown" and "ToggledInactive" >+states are used instead for buttons which have one of the >+.IR MwmDecorMax ", " MwmDecorShade " or " MwmDecorStick >+hints, if the window is maximized, shaded or sticky, respectively. >+.EX >+AddToDecor Default >+ + ButtonStyle 6 \\ >+ Vector 4 50x25@1 85x75@0 15x75@0 50x25@1 >+ + ButtonStyle 6 ToggledActiveUp \\ >+ Vector 4 50x75@0 85x25@1 15x25@0 50x75@0 >+ + ButtonStyle 6 ToggledActiveDown \\ >+ Vector 4 50x75@0 85x25@1 15x25@0 50x75@0 >+ + ButtonStyle 6 ToggledInactive \\ >+ Vector 4 50x75@0 85x25@1 15x25@0 50x75@0 >+ + ButtonStyle 6 - MwmDecorShade >+Mouse 0 6 N WindowShade >+.EE >+If >+.I state >+is "ActiveUp", "ActiveDown", "Inactive", or a "Toggled" variant, >+that particular button state is set. If >+.I state >+is omitted, every state is set. Specifying a style destroys the >+current style (use >+.B AddButtonStyle >+to avoid this). >+ >+If >+.I style >+is omitted, then state-dependent flags can be set for the primary >+button style without destroying the current style. Examples (each >+line should be considered independent): >+.EX >+ButtonStyle Left -- flat >+ButtonStyle All ActiveUp (-- flat) \\ >+ Inactive (-- flat) >+.EE >+The first line sets every state of the left buttons to flat, while >+the second sets only the "ActiveUp" and "Inactive" states of every >+button to flat (only flags are changed; the buttons' individual >+styles are not changed). >+ >+If you want to reset all buttons to their defaults: >+.EX >+ButtonStyle Reset >+.EE >+To reset the "ActiveUp" button state of button 1 to the default: >+.EX >+ButtonStyle 1 ActiveUp Default >+.EE >+To reset all button states of button 1 to the default of >+button number 2: >+.EX >+ButtonStyle 1 Default 2 >+.EE >+For any button, multiple >+.I state >+definitions can be given on one line by enclosing the >+.IR style " and " flags >+in parentheses. If only one definition per line is given the >+parentheses can be omitted. >+ >+.I flags >+affect the specified >+.IR state . >+If a >+.RI ' ! ' >+is prefixed to any >+.IR flag , >+its behavior is negated. The available state-dependent flags for >+all styles are described here (the >+.B ButtonStyle >+entry deals with state-independent flags). >+ >+.I Raised >+causes a raised relief pattern to be drawn. >+ >+.I Sunk >+causes a sunken relief pattern to be drawn. >+ >+.I Flat >+inhibits the relief pattern from being drawn. >+ >+.I UseTitleStyle >+causes the given button state to render the current title style >+before rendering the button's own styles. The >+.IR Raised ", " Flat " and " Sunk >+.B TitleStyle >+flags are ignored since they are redundant in this context. >+ >+.I UseBorderStyle >+causes the button to inherit the decorated >+.B BorderStyle >+options. >+ >+.IR Raised ", " Sunk " and " Flat >+are mutually exclusive, and can be specified for the initial >+.B ButtonStyle >+only. >+.IR UseTitleStyle " and " UseBorderStyle >+are also mutually exclusive (both can be off however). The default is >+.I Raised >+with both >+.I UseBorderStyle " and " UseTitleStyle >+left unset. >+ >+.I Important note >+for the "ActiveDown" state: When a button is pressed, the relief >+is inverted. Because of this, to obtain a sunken "ActiveDown" >+state you must specify the opposite of the desired relief (i.e. to >+obtain a pressed-in look which is raised, specify >+.I Sunk >+for "ActiveDown"). This behavior is consistent, but may seem >+confusing at first. The same applies to the "Toggled" state. >+ >+Button styles are classified as non-destructive, partially >+destructive, or fully destructive. Non-destructive styles do not >+affect the image. Partially destructive styles can obscure some or >+all parts of the underlying image (i.e. >+.IR Pixmap ). >+Fully destructive styles obscure the entire underlying image (i.e. >+.I Solid >+or one of the >+.I gradient >+styles). Thus, if stacking styles with >+.BR AddButtonStyle " (or " AddTitleStyle >+for title-bars), use care in sequencing styles to minimize redraw. >+ >+The available styles and their arguments now follow. >+ >+The >+.I Simple >+style does nothing. There are no arguments, and this style is an >+example of a non-destructive button style. >+ >+The >+.I Default >+style conditionally accepts one argument: a number which specifies >+the default button number to load. If the style command given is >+.BR ButtonStyle " or " AddButtonStyle , >+the argument is optional (if given, overrides the current button). >+If a command other than >+.BR ButtonStyle " or " AddButtonStyle >+is used, the number must be specified. >+ >+The >+.I Solid >+style fills the button with a solid color. The relief border >+color is not affected. The color should be specified as a single >+argument. This style is fully destructive. >+ >+The >+.I "Vector num" >+.IR X x Y @ C " ..." >+style draws a line pattern. Since this is a standard button style, >+the keyword >+.I Vector >+is optional, >+.I num >+is a number of point specifications of the form >+.IR X x Y @ C . >+.IR X " and " Y >+are point coordinates inside the button, given in percents >+(from 0 to 100). >+.I C >+specifies a line color (0 - the shadow color, 1 - the highlight color, >+2 - the background color, 3 - the foreground color). >+The first point color is not used. >+You can use up to 32 points in a line pattern. >+This style is partially destructive. >+ >+The specification is a little cumbersome: >+.EX >+ButtonStyle 2 Vector 4 50x30@1 70x70@0 \\ >+ 30x70@0 50x30@1 >+.EE >+then the button 2 decoration uses a 4-point pattern consisting of >+a line from (x=50,y=30) to (70,70) in the shadow color (@0), and >+then to (30,70) in the shadow color, and finally to (50,30) in the >+highlight color (@1). Is that too confusing? See the fvwm web >+pages for some examples with screenshots. >+ >+A more complex example of >+.IR Vector : >+.EX >+ButtonStyle 8 Vector 10 45x65@2 45x75@3 20x75@3 20x50@3 \\ >+ 35x50@3 35x65@1 35x25@1 75x25@1 75x65@0 35x65@0 >+ButtonStyle 0 Vector 10 45x65@2 45x75@0 20x75@0 20x50@1 \\ >+ 45x50@1 45x65@0 75x65@3 75x25@3 35x25@3 35x47@3 >+.EE >+The >+.I ?Gradient >+styles denote color gradients. Fill in the question mark with any >+one of the defined gradient types. Please refer to the >+.B COLOR GRADIENTS >+section for a description of the gradient syntax. The gradient >+styles are fully destructive. >+ >+The >+.I Pixmap >+style displays a pixmap. A pixmap should be specified as an >+argument. For example, the following would give button 2 the same >+pixmap for both states, and button 4 different pixmaps for the up, >+down and inactive states. >+.EX >+ButtonStyle 2 Pixmap my_pixmap.xpm >+ButtonStyle 4 ActiveUp (Pixmap up.xpm) \\ >+ ActiveDown (Pixmap down.xpm) >+ButtonStyle 4 Inactive Pixmap inactive.xpm >+.EE >+The pixmap specification can be given as an absolute or relative >+pathname (see >+.BR ImagePath ). >+If the pixmap cannot be found, the button style reverts to >+.IR Simple . >+Flags specific to the >+.I Pixmap >+style are >+.IR Left ", " Right ", " >+.IR Top ", and " Bottom . >+These can be used to justify the pixmap (default is centered for >+both directions). Pixmap transparency is used for the color >+"None." This style is partially destructive. >+ >+The >+.I MiniIcon >+style draws the window's miniature icon in the button, which is >+specified with the >+.I MiniIcon >+option of the >+.B Style >+command. This button style accepts no arguments. Example: >+.EX >+Style * MiniIcon mini-bx2.xpm >+Style xterm MiniIcon mini-term.xpm >+Style Emacs MiniIcon mini-doc.xpm >+ >+ButtonStyle 1 MiniIcon >+.EE >+The >+.I TiledPixmap >+style accepts a pixmap to be tiled as the button background. One >+pixmap is specified as an argument. Pixmap transparency is not >+used. This style is fully destructive. >+ >+.TP >+.BI "ButtonStyle " button " - [!]" flag " ..." >+Sets state-independent flags for the specified >+.IR button . >+State-independent flags affect button behavior. Each >+.I flag >+is separated by a space. If a >+.RI ' ! ' >+is prefixed to the flag then the behavior is negated. The special >+flag >+.I Clear >+clears any existing flags. >+ >+The following flags are usually used to tell fvwm which buttons >+should be affected by mwm function hints (see >+.I MwmFunctions >+option of the >+.B Style >+command. This is not done automatically since you might have >+buttons bound to complex functions, for instance. >+ >+.I MwmDecorMenu >+should be assigned to title-bar buttons which display a menu. The >+default assignment is the leftmost button. When a window with the >+.I MwmFunctions >+.B Style >+option requests not to show this button, it is hidden. >+ >+.I MwmDecorMin >+should be assigned to title-bar buttons which minimize or iconify >+the window. The default assignment is the second button over from >+the rightmost button. When a window with the >+.I MwmFunctions >+.B Style >+option requests not to show this button, it is hidden. >+ >+.I MwmDecorMax >+should be assigned to title-bar buttons which maximize the >+window. The default assignment is the rightmost button. When a >+window with the >+.I MwmFunctions >+.B Style >+option requests not to show this button, it is hidden. When the >+window is maximized, the vector pattern on the button looks >+pressed in. >+ >+.I MwmDecorShade >+should be assigned to title-bar buttons which shade the window >+(see >+.B WindowShade >+command). When the window is shaded, the vector pattern on the >+button looks pressed in. >+ >+.I MwmDecorStick >+should be assigned to title-bar buttons which make the window >+sticky. When the window is sticky, the vector pattern on the >+button looks pressed in. >+ >+.TP >+.BI "ChangeDecor " decor >+Changes the decor of a window to >+.IR decor . >+.I decor >+is "Default" or the name of a decor defined with >+.BR AddToDecor . >+If >+.I decor >+is invalid, nothing occurs. If called from somewhere in a window >+or its border, then that window is affected. If called from the >+root window the user is allowed to select the target window. >+.B ChangeDecor >+only affects attributes which can be set using the >+.B AddToDecor >+command. >+.EX >+ChangeDecor CustomDecor1 >+.EE >+ >+.TP >+.BI "DestroyDecor [" recreate "] " decor >+Deletes the >+.I decor >+defined with >+.BR AddToDecor , >+so that subsequent references to it are no longer valid. Windows >+using this >+.I decor >+revert to the "Default" decor. The optional parameter >+.I recreate >+tells fvwm not to throw away the decor completely but to throw >+away only its contents. If the decor is created again later, >+windows do not use it before the >+.I UseDecor >+style is applied again unless the decor was destroyed with the >+.I recreate >+option. The decor named "Default" cannot be destroyed. >+.EX >+DestroyDecor CustomDecor1 >+.EE >+ >+.TP >+.BI "TitleStyle [" justification "] [" height " [" num "]]" >+Sets attributes for the title-bar. Justifications can be >+.IR Centered ", " RightJustified " or " LeftJustified . >+.I height >+sets the title bar's height to an amount in pixels. Defaults are >+.I Centered >+and the window's font height. To reset the font height to the >+default value, omit the >+.I num >+argument after the >+.I height >+keyword. Example: >+.EX >+TitleStyle LeftJustified Height 24 >+.EE >+ >+.IP "\fBTitleStyle [\fP \fIstate\fP \ >+\fB] [\fP \fIstyle\fP \ >+\fB] [-- [!]\fP \fIflag\fP \ >+\fB...]\fP" >+Sets the style for the title-bar. >+.I state >+can be one of "ActiveUp", "ActiveDown", or "Inactive". If >+.I state >+is omitted, then the >+.I style >+is added to every state. If parentheses are placed around the >+.IR style " and " flags , >+then multiple state definitions can be given per line. >+.I style >+can be omitted so that flags can be set while not destroying the >+current style. >+ >+If a >+.RI ' ! ' >+is prefixed to any >+.IR flag , >+its behavior is negated. Valid flags for each state include >+.IR Raised ", " Flat " and " Sunk >+(these are mutually exclusive). The default is >+.IR Raised . >+See the note in >+.B ButtonStyle >+regarding the "ActiveDown" state. Examples: >+.EX >+TitleStyle ActiveUp HGradient 16 navy black >+TitleStyle ActiveDown (Solid red -- flat) \\ >+ Inactive (TiledPixmap wood.xpm) >+TitleStyle ActiveUp (-- Flat) ActiveDown \\ >+ (-- Raised) Inactive (-- Flat) >+.EE >+This sets the "ActiveUp" state to a horizontal gradient, the >+"ActiveDown" state to solid red, and the "Inactive" state to a >+tiled wood pixmap. Finally, "ActiveUp" is set to look flat, while >+"ActiveDown" set to be sunk (the >+.I Raised >+flag for the "ActiveDown" state causes it to appear sunk due to >+relief inversion), and "Inactive" is set to flat as well. An >+example which sets flags for all states: >+.EX >+TitleStyle -- flat >+.EE >+For a flattened look: >+.EX >+TitleStyle -- flat >+ButtonStyle All ActiveUp (-- flat) Inactive \\ >+ (-- flat) >+.EE >+ >+.TP >+.BI "UpdateDecor [" decor "]" >+This command is kept mainly for backwards compatibility. Since >+all elements of a decor are updated immediately when they are >+changed, this command is mostly useless. >+ >+Updates window decorations. >+.I decor >+is an optional argument which specifies the >+.I decor >+to update. If given, only windows which are assigned to that >+particular >+.I decor >+are updated. This command is useful, for instance, after a >+.BR ButtonStyle ", " TitleStyle " or " BorderStyle >+(possibly used in conjunction with >+.BR AddToDecor ). >+Specifying an invalid decor results in all windows being >+updated. This command is less disturbing than >+.BR Recapture , >+but does not affect window style options as >+.B Recapture >+does. >+ >+ >+.SS COMMANDS CONTROLLING THE VIRTUAL DESKTOP >+ >+.IP "\fBDesk\fP \fIarg1\fP \ >+\fB[\fP \fIarg2\fP \ >+\fB] [\fP \fImin max\fP \ >+\fB]\fP" >+This command has been renamed. Please see >+.B GotoDesk >+command. >+ >+.TP >+.BI "DeskTopSize " Horizontal x Vertical >+Defines the virtual desktop size in units of the physical screen >+size. >+ >+.TP >+.BI "EdgeResistance " "scrolling moving " [ "xinerama-moving" ] >+Tells how hard it should be to change the desktop viewport by >+moving the mouse over the edge of the screen and how hard it >+should be to move a window over the edge of the screen. >+ >+The first parameter tells how many milliseconds the pointer must >+spend on the screen edge before fvwm moves the viewport. This is >+intended for people who use >+.EX >+EdgeScroll 100 100 >+.EE >+but find themselves accidentally flipping pages when they don't >+want to. >+ >+The second parameter tells how many pixels over the edge of the >+screen a window's edge must move before it actually moves >+partially off the screen. By default the viewport is moved a full >+page in the requested direction, but if you used >+.B EdgeScroll >+and set any values other than zero they is used instead. >+ >+Note that, with >+.EX >+EdgeScroll 0 0 >+.EE >+it is still possible to move or resize windows across the edge of >+the current screen. By making the first parameter to >+.B EdgeResistance >+10000 this type of motion is impossible. With >+.B EdgeResistance >+less than 10000 but greater than 0 moving over pages becomes >+difficult but not impossible. See also >+.BR EdgeThickness . >+ >+The optional third parameter does the same as the second, but for >+individual Xinerama screens. If omitted, >+.I xinerama-moving >+will be set to the value of >+.IR moving . >+Set >+.I xinerama-moving >+to zero to ignore individual screen edges. >+ >+.TP >+.BI "EdgeScroll " horizontal "[" p "] " vertical "[" p "]" >+Specifies the percentage of a page to scroll when the cursor hits >+the edge of a page. A trailing >+.RI ' p ' >+changes the interpretation to mean pixels. If you don't want any >+paging or scrolling when you hit the edge of a page include >+.EX >+EdgeScroll 0 0 >+.EE >+in your >+.I .fvwm2rc >+file, or possibly better, set the >+.B EdgeThickness >+to zero. See the >+.B EdgeThickness >+command. If you want whole pages, use >+.EX >+EdgeScroll 100 100 >+.EE >+Both >+.IR horizontal " and " vertical >+should be positive numbers. >+ >+If the >+.IR horizontal " and " vertical >+percentages are multiplied by 1000 then scrolling wraps around at >+the edge of the desktop. If >+.EX >+EdgeScroll 100000 100000 >+.EE >+is used fvwm scrolls by whole pages, wrapping around at the edge >+of the desktop. >+ >+.TP >+.BI "EdgeThickness " 0 | 1 | 2 >+This is the width or height of the invisible window that fvwm >+creates on the edges of the screen that are used for the edge >+scrolling feature. >+ >+In order to enable page scrolling via the mouse, four windows >+called the "pan frames" are placed at the very edge of the >+screen. This is how fvwm detects the mouse's presence at the >+window edge. Because of the way this works, they need to be at the >+top of the stack and eat mouse events, so if you have any kind of >+error along the lines of: "mouse clicks at the edge of the screen >+do the wrong thing" you're having trouble with the pan frames and >+(assuming you don't use the mouse to flip between pages) should >+set the EdgeThickness to 0. >+ >+A value of >+.I 0 >+completely disables mouse edge scrolling, even while dragging a >+window. >+.I 1 >+gives the smallest pan frames, which seem to work best except on >+some servers. >+ >+.I 2 >+is the default. >+ >+Pan frames of >+.IR 1 " or " 2 >+pixels can sometimes be confusing, for example, if you drag a >+window over the edge of the screen, so that it straddles a pan >+frame, clicks on the window, near the edge of the screen are >+treated as clicks on the root window. >+ >+.IP "\fBGotoDesk\fP \fIprev\fP \ >+\fB|\fP \fIarg1\fP \ >+\fB[\fP \fIarg2\fP \ >+\fB] [\fP \fImin max\fP \ >+\fB]\fP" >+Switches the current viewport to another desktop (workspace, >+room). >+ >+The command takes 1, 2, 3, or 4 arguments. A single argument is >+interpreted as a relative desk number. Two arguments are >+understood as a relative and an absolute desk number. Three >+arguments specify a relative desk and the minimum and maximum of >+the allowable range. Four arguments specify the relative, >+absolute, minimum and maximum values. (Desktop numbers can be >+negative). If a literal >+.I prev >+is given as the single argument, the last visited desk number is >+used. >+ >+If >+.I arg1 >+is non zero then the next desktop number is the current desktop >+number plus >+.IR arg1 . >+ >+If >+.I arg1 >+is zero then the new desktop number is >+.IR arg2 . >+(If >+.I arg2 >+is not present, then the command has no effect.) >+ >+If >+.IR min " and " max >+are given, the new desktop number is no smaller than >+.I min >+and no bigger than >+.IR max . >+Values out of this range are truncated (if you gave an absolute >+desk number) or wrapped around (if you gave a relative desk >+number). >+ >+The syntax is the same as for >+.BR MoveToDesk , >+which moves a window to a different desktop. >+ >+The number of active desktops is determined dynamically. Only >+desktops which contain windows or are currently being displayed >+are active. Desktop numbers must be between 2147483647 and >+-2147483648 (is that enough?). >+ >+.TP >+.BI "GotoDeskAndPage " prev " | " "desk xpage ypage" >+Switches the current viewport to another desktop and page, similar >+to the >+.BR GotoDesk " and " GotoPage >+commands. The new desk is >+.I desk >+and the new page is >+.RI ( xpage , ypage ). >+ >+.IP "\fBGotoPage\fP \fIprev\fP \ >+\fB|\fP \fIx\fP \ >+\fB[\fP \fIp\fP \ >+\fB]\fP \fIy\fP \ >+\fB[\fP \fIp\fP \ >+\fB]\fP" >+Moves the desktop viewport to page (x,y). The upper left page is >+(0,0), the upper right is (M,0), where M is one less than the >+current number of horizontal pages specified in the >+.B DeskTopSize >+command. The lower left page is (0,N), and the lower right page >+is (M,N), where N is the desktop's vertical size as specified in >+the >+.B DeskTopSize >+command. To switch to a page relative to the current one add a >+trailing >+.RI ' p ' >+after any or both numerical arguments. To go to last visited page >+use >+.I prev >+as the first argument. The >+.B GotoPage >+function should not be used in a pop-up menu. >+ >+Examples: >+.EX >+# Go to page (2,3) >+GotoPage 2 3 >+ >+# Go to lowest and rightmost page >+GotoPage -1 -1 >+ >+# Go to last page visited >+GotoPage prev >+ >+# Go two pages to the right and one page up >+GotoPage +2p -1p >+.EE >+ >+.IP "\fBScroll\fP \fIhorizonal\fP \ >+\fB[\fP \fIp\fP \ >+\fB]\fP \fIvertical\fP \ >+\fB[\fP \fIp\fP \ >+\fB]\fP" >+Scrolls the virtual desktop's viewport by >+.I horizontal >+pages in the x-direction and >+.I vertical >+pages in the y-direction. Either or both entries may be negative. >+Both >+.IR horizontal " and " vertical >+values are expressed in percent of pages, so >+.EX >+Scroll 100 100 >+.EE >+means to scroll down and left by one full page. >+.EX >+Scroll 50 25 >+.EE >+means to scroll left half a page and down a quarter of a page. >+The >+.B Scroll >+function should not be called from pop-up menus. Normally, >+scrolling stops at the edge of the desktop. >+ >+If the >+.IR horizontal " and " vertical >+percentages are multiplied by 1000 then scrolling wraps around at >+the edge of the desktop. If >+.EX >+Scroll 100000 0 >+.EE >+is executed over and over fvwm moves to the next desktop page on >+each execution and wraps around at the edge of the desktop, so >+that every page is hit in turn. >+ >+If the letter >+.RI ' p ' >+is appended to each coordinate >+.RI ( horizontal " and/or " vertical ), >+then the scroll amount is measured in pixels. >+ >+.TP >+.BI "Xinerama " bool >+Enables Xinerama support if the boolean argument is true and >+disables it if the argument is false. Calling this command >+without arguments turns on Xinerama support it was disabled before >+and turns it off if it was enabled. For example: >+.EX >+# Turn Xinerama support on, use primary screen 2 >+XineramaPrimaryScreen 2 >+Xinerama on >+#Turn it off again >+Xinerama off >+.EE >+ >+.TP >+.BI "XineramaPrimaryScreen [" primary-screen "]" >+Takes an integer number or 'g' or 'c' as its argument. A number >+is taken as the number of the Xinerama screen that is to be used >+as the primary screen. The primary screen can be used as the >+preferred screen to place windows with >+.EX >+XineramaPrimaryScreen <screen number> >+Style * StartsOnScreen p >+.EE >+The primary screen is used in some of the modules and for the >+default icon box too. Any number that is zero or more is taken as >+the primary screen's number. Instead, the letter 'c' indicates to >+use the curent screen (containing the pointer) whenever the >+primary screen is used. This may be very confusing under some >+circumstances. With >+'g', the global screen is used as the primary screen, effectively >+disabling the primary screen. Calling this function with any >+other argument (including none) resets the primary screen to 0. >+ >+.TP >+.BI "XineramaSls [" bool "]" >+For multi-screen implementations other than Xinerama, such as >+Single Logical Screen, it is possible to simulate a Xinerama >+configuration if the total screen seen by FVWM is made up of >+equal sized monitors in a rectangular grid. The >+.B XineramaSls >+command turns SLS support on or off or toggles it to the opposite >+state, depending on if the boolean argument is "True", "False" or >+"toggle". If no argument is given, this is treated like "toggle". >+The default layout uses 1 by one screens. To configure the >+layout, use the >+.B XineramaSlsSize >+command. >+ >+.TP >+.BI "XineramaSlsSize " Horizontal x Vertical >+This command configures the layout of the Single Logical screen >+feature. It takes two arguments, >+.IR Horizontal " and " Vertical >+which must be an integer value dividing evenly into the total >+desktop width, and height height. For an example with two >+monitors side by side which appear as one screen through the >+X-Server with the right screen as the primary screen, use: >+.EX >+XineramaSlsSize 2x1 >+XineramaSlsOn >+XineramaPrimaryScreen 1 >+XineramaOn >+.EE >+ >+ >+.SS COMMANDS FOR USER FUNCTIONS AND SHELL COMMANDS >+ >+.IP "\fBAddToFunc [\fP \fIname\fP \ >+\fB[\fP \fII\fP \ >+\fB|\fP \fIM\fP \ >+\fB|\fP \fIC\fP \ >+\fB|\fP \fIH\fP \ >+\fB|\fP \fID action\fP \ >+\fB]]\fP" >+Begins or adds to a function definition. Here is an example: >+.EX >+AddToFunc Move-or-Raise I Raise >+ + M Move >+ + D Lower >+.EE >+The function name is "Move-or-Raise", and could be invoked from a menu >+or a mouse binding or key binding: >+.EX >+Mouse 1 TS A Move-or-Raise >+.EE >+The >+.I name >+must not contain embedded whitespace. No guarantees are made >+whether function names with embedded whitespace work or not. This >+behaviour may also change in the future without further notice. >+The letter before the >+.I action >+tells what kind of action triggers the command which follows it. >+.RI ' I ' >+stands for "Immediate", and is executed as soon as the function is >+invoked. >+.RI ' M ' >+stands for "Motion", i.e. if the user starts moving the mouse. >+.RI ' C ' >+stands for "Click", i.e., if the user presses and releases the >+mouse. >+.RI ' H ' >+stands for "Hold", i.e. if the user presses a mouse button and >+holds it down for more than >+.B ClickTime >+milliseconds. >+.RI ' D ' >+stands for "Double-click". The action >+.RI ' I ' >+causes an action to be performed on the button-press, if the >+function is invoked with prior knowledge of which window to act >+on. >+ >+There is a number of predefined symbols that are replaced by >+certain values if they appear on the command line. Please refer >+to the >+.B COMMAND EXPANSION >+section for details. >+ >+Examples: >+ >+If you call >+.EX >+Key F10 R A Function MailFunction \\ >+ xmh "-font fixed" >+.EE >+and "MailFunction" is >+.EX >+AddToFunc MailFunction >+ + I Next ($0) Iconify off >+ + I Next (AcceptsFocus, $0) focus >+ + I None ($0) Exec exec $0 $1 >+.EE >+Then the last line of the function becomes >+.EX >+ + I None (xmh) Exec exec xmh -font fixed >+.EE >+The expansion is performed as the function is executed, so you can >+use the same function with all sorts of different arguments. You >+could use >+.EX >+Key F11 R A Function MailFunction \\ >+ zmail "-bg pink" >+.EE >+in the same >+.IR .fvwm2rc , >+if you wanted. An example of using "$w" is: >+.EX >+AddToFunc PrintFunction >+ + I Raise >+ + I Exec xdpr -id $w >+.EE >+Note that "$$" is expanded to '$'. >+ >+Another example: bind right mouse button within the window button >+number 6 (this is a minimize button for the win95 theme) to >+iconify all windows of the same resource: >+.EX >+AddToFunc FuncIconifySameResource "I" \\ >+ All ($r) Iconify on >+Mouse 3 6 A FuncIconifySameResource >+.EE >+ >+.TP >+.BI "Beep" >+As might be expected, this makes the terminal beep. >+ >+.TP >+.BI "DestroyFunc " function >+Deletes a function, so that subsequent references to it are no >+longer valid. You can use this to change the contents of a >+function during a fvwm session. The function can be rebuilt using >+.BR AddToFunc . >+.EX >+DestroyFunc PrintFunction >+.EE >+ >+.TP >+.BI "Echo " string >+Prints a message to >+.IR stderr . >+Potentially useful for debugging things in your >+.IR .fvwm2rc . >+.EX >+Echo Beginning style definitions... >+.EE >+ >+.TP >+.BI "Exec " command >+Executes >+.IR command . >+You should not use an ampersand '&' at the end of the command. You >+probably want to use an additional "exec" at the beginning of >+.IR command . >+Without that, the shell that fvwm invokes to run your command >+stays until the command exits. In effect, you'll have twice as >+many processes running as you need. Note that some shells are >+smart enough to avoid this, but it never hurts to include the >+"exec" anyway. >+ >+The following example binds function key >+.SM F1 >+in the root window, with no modifiers, to the exec function. The >+program rxvt is started with an assortment of options. >+ >+.EX >+Key F1 R N Exec exec rxvt -fg yellow -bg blue \\ >+ -e /bin/tcsh >+.EE >+Note that this function doesn't wait for >+.I command >+to complete, so things like: >+.EX >+Exec "echo AddToMenu ... > /tmp/file" >+Read /tmp/file >+.EE >+do not work reliably. >+ >+.TP >+.BI "ExecUseShell [" shell "]" >+Makes the >+.B Exec >+command use the specified shell, or the value of the >+.I $SHELL >+environment variable if no shell is specified, instead of the >+default Bourne shell >+.RI ( /bin/sh ). >+.EX >+ExecUseShell >+ExecUseShell /usr/local/bin/tcsh >+.EE >+ >+.TP >+.BI "Function " FunctionName >+Used to bind a previously defined function to a key or mouse >+button. The following example binds mouse button 1 to a function >+called "Move-or-Raise", whose definition was provided as an >+example earlier in this man page. After performing this binding >+fvwm executes the "move-or-raise" function whenever button 1 is >+pressed in a window's title-bar. >+.EX >+Mouse 1 T A Function Move-or-Raise >+.EE >+The keyword >+.B Function >+may be omitted if >+.I FunctionName >+does not coincide with a fvwm built-in function name >+ >+.TP >+.BI "Nop" >+Does nothing. This is used to insert a blank line or separator in a >+menu. If the menu item specification is >+.EX >+Nop " " >+.EE >+then a blank line is inserted. If it looks like >+.EX >+Nop "" >+.EE >+then a separator line is inserted. Can also be used as the >+double-click action for >+.BR Menu " or " Popup . >+ >+.TP >+.BI "PipeRead " command " [" quiet "]" >+Causes fvwm to read commands from the output of the >+.IR command . >+This >+.I command >+is executed by >+.I /bin/sh >+as if you typed it on the command line. If the command consists >+of more than one word it must be quoted. Useful for building up >+dynamic menu entries based on a directories contents, for >+example. If the keyword >+.I Quiet >+follows the command no message is produced if the >+.I command >+is not found. >+ >+Example: >+.EX >+AddToMenu HomeDirMenu >+PipeRead 'for i in $HOME/*; \\ >+ do echo "+ $i Exec xterm -e vi $i"; done' >+.EE >+ >+.TP >+.BI "Read " filename " [" quiet "]" >+Causes fvwm to read commands from the file named >+.IR filename . >+If the keyword >+.I Quiet >+follows the command no message is produced if the file is not >+found. If the file name does not begin with a slash ('/'), fvwm >+looks in the user's data directory, then the system data >+directory. The user's data directory is by default >+.IR $HOME/.fvwm . >+It can be overridden by exporting >+.I FVWM_USERDIR >+set to any other directory. >+ >+.TP >+.BI "SetEnv " "variable [value]" >+Set an environment variable to a new value, similar to the shell's >+export or setenv command. The >+.I variable >+and its >+.I value >+are inherited by processes started directly by fvwm. This can be >+especially useful in conjunction with the >+.B FvwmM4 >+module. For example: >+.EX >+SetEnv height HEIGHT >+.EE >+makes the FvwmM4-set variable >+.I HEIGHT >+usable by processes started by fvwm as the environment variable >+.IR $height . >+If >+.I value >+includes whitespace, you should enclose it in quotes. If no >+.I value >+is given, the >+.I variable >+is deleted from the environment as if >+.B UnsetEnv >+had been called. >+ >+.TP >+.BI "Silent " command >+A number of built in functions require a window to operate on. If >+no window was selected when such a function is invoked the user is >+asked to select a window. Sometimes this behavior is unwanted, >+for example if the function was called by a module and the window >+that was selected at first does not exist anymore. You can >+prevent this by putting >+.B Silent >+in front of the fvwm >+.IR command . >+If a function that needs a window is called with >+.B Silent >+without a window selected, it simply returns without doing >+anything. If >+.B Silent >+is used on a user defined function it affects all function and sub >+function calls until the original function exits. >+ >+Another usage of >+.B Silent >+is with binding commands >+.BR Key ", " PointerKey " and " Mouse , >+this disables error messages. >+ >+Examples: >+.EX >+Silent Move 0 0 >+Silent User_defined_function >+# don't complain on keabords without "Help" key >+Silent Key Help R A Popup HelpMenu >+.EE >+ >+.TP >+.BI "UnsetEnv " "variable" >+Unset an environment variable, similar to shell's export or >+unsetenv command. The >+.I variable >+then is removed from the environment array inherited by processes >+started directly by fvwm. >+ >+.TP >+.BI "Wait " windowname >+This built-in is intended to be used in fvwm functions only. It >+causes execution of a function to pause until a new window with >+the title >+.I windowname >+appears. Fvwm remains partially functional during a wait. This >+is particularly useful in the "InitFunction" if you are trying to >+start windows on specific desktops: >+.EX >+AddToFunc InitFunction >+ + I exec xterm -geometry 80x64+0+0 >+ + I Wait xterm >+ + I Desk 0 2 >+ + I Exec exec xmh -font fixed -geometry \\ >+ 507x750+0+0 >+ + I Wait xmh >+ + I Desk 0 0 >+.EE >+The above function starts an xterm on the current desk, waits for >+it to map itself, then switches to desk 2 and starts an xmh. >+After the xmh window appears control moves to desk 0. >+ >+You can escape from a >+.B Wait >+pause by pressing >+.SM Ctrl-Alt-Escape >+(where >+.SM Alt >+is the first modifier). To redefine this key sequence see the >+.B EscapeFunc >+command. >+ >+ >+.SS CONDITIONAL COMMANDS >+ >+.TP >+.BI "All [(" conditions ")] " command >+Execute. >+.I command >+on all windows meeting the conditions. >+.I Conditions >+are used exactly as with the >+.B Current >+command. >+ >+.TP >+.BI "Current [(" condition ... ")] " command >+Performs >+.I command >+on the currently focused window if it satisfies all >+.IR conditions . >+The >+.IR conditions >+are a list of keywords from the list below and are separated by >+commas or whitespace. Conditions include >+"AcceptsFocus", "!AcceptsFocus" >+"Iconic", "!Iconic", >+"Visible", "!Visible", >+"Raised", "!Raised", >+"Layer [n]", >+"Sticky", "!Sticky", >+"Maximized", "!Maximized", >+"Shaded", "!Shaded", >+"Transient", "!Transient", >+"PlacedByButton3", "!PlacedByButton3", >+"PlacedByFvwm", "!PlacedByFvwm", >+"CurrentDesk", "CurrentPage", "CurrentScreen" >+"CurrentGlobalPage", "CurrentPageAnyDesk" and "CurrentGlobalPageAnyDesk". >+In addition, the >+.I condition >+may include one window name to match to. The window name may >+include the wildcards '*' and '?'. The window name, icon name, >+class, and resource are considered when attempting to find a >+match. The window name can begin with '!' which prevents >+.I command >+if any of the window name, icon name, class or resource match. >+ >+The "AcceptsFocus" condition excludes all windows that do not want >+the input focus (the application has set the "Input hints" for the >+window to False) and do not use the >+.I Lenience >+option of the >+.B Style >+command. Also, all windows using the >+.I NoFocus >+style are ignored. >+ >+The "CurrentDesk" condition excludes all window that are not on >+the current desk. >+ >+The "CurrentPage" condition excludes all window that are not on >+the current desk or not on the current page. If Xinerama support >+is enabled, only windows on the screen that contains the mouse >+pointer are considered to match. >+ >+The "CurrentGlobalPage" condition excludes all window that are not >+on the current desk or not on the current page. The screen does >+not matter if Xinerama support is enabled. >+ >+The "CurrentScreen" and "CurrentPageAnyDesk" conditions exclude >+all window that are not on the current page but that may be on any >+desk. >+ >+The "CurrentGlobalPage" condition excludes all window that are not >+on the current desk or not on the current page. If Xinerama >+support is enabled, only windows on the screen that contains the >+mouse pointer are considered to match. >+ >+The "CurrentGlobalPageAnyDesk" condition excludes all window that >+are not on the current page but that may be on any desk. The >+screen does not matter if Xinerama support is enabled. >+ >+The argument of the "Layer" condition defaults to the layer of the >+focus window. >+ >+The "PlacedByButton3" condition is fulfilled if the last >+interactive motion of the window (with the >+.B Move >+command) was ended by pressing mouse button 3. This is especially >+useful with the >+.I ManualPlacement >+option of the >+.B Style >+command. >+ >+The "PlacedByFvwm" condition excludes all windows that have been placed >+manually or by using the user or program position hint. >+ >+Note that earlier versions of fvwm required the conditions to be >+enclosed in brackets instead of parentheses (this is still >+supported for backwards compatibility). >+ >+.TP >+.BI "Direction " direction " [(" conditions ")] " command >+Performs >+.I command >+(typically >+.BR Focus ) >+on a window in the given direction which satisfies all >+.IR conditions . >+Conditions are the same as for >+.BR Current . >+The >+.I direction >+may be one of "North", "Northeast", "East", "Southeast", "South", >+"Southwest", "West" and "Northwest". Which window >+.B Direction >+selects depends on angle and distance between the center points of >+the windows. Closer windows are considered a better match than >+those farther away. >+ >+.TP >+.BI "Next [(" conditions ")] " command >+Performs >+.I command >+(typically >+.BR Focus ) >+on the next window which satisfies all >+.IR conditions . >+Conditions are the same as for >+.B Current >+with the addition of "CirculateHit" which overrides the >+.IB "CirculateSkip " Style >+attribute, "CirculateHitIcon" which overrides the >+.IB "CirculateSkipIcon " Style >+attribute for iconified windows and "CirculateHitShaded" which >+does the same for shaded windows. >+ >+.TP >+.BI "None [(" conditions ")] " command >+Performs >+.I command >+if no window which satisfies all >+.I conditions >+exists. Conditions are the same as for >+.BR Next . >+ >+.TP >+.BI "Pick [(" conditions ")] " command >+.B Pick >+works like >+.B Function >+if invoked in the context of a window. If invoked in the root >+window, it first asks the user to pick a window and then executes the >+.I command >+in the context of that window. This avoids annoying multiple >+selections with complex functions. The command is executed only >+if the given >+.I conditions >+are met. The conditions are the same as for >+.BR Next . >+ >+.TP >+.BI "Prev [(" conditions ")] " command >+Performs >+.I command >+(typically >+.BR Focus ) >+on the previous window which satisfies all >+.IR conditions . >+Conditions are the same as for >+.BR Next . >+ >+.TP >+.BI "ThisWindow [(" conditions ")] " command >+.B ThisWindow >+executes the specified >+.I command >+in the context of the current operand window. If there is no >+operand window (it is invoked in the root window), the command is >+ignored. >+.B ThisWindow >+is always non-interactive. The command is executed only if the >+given >+.I conditions >+are met. The conditions are the same as for >+.BR Current . >+It returns -1 if used outside a window context. >+ >+.IP "\fBWindowId [\fP \fIid\fP \ >+\fB] [(\fP \fIconditions\fP \ >+\fB)] | [\fP \fIroot\fP \ >+\fB[\fP \fIscreen\fP \ >+\fB]]\fP \fIcommand" >+The >+.B WindowId >+function is similar to the >+.BR Next " and " Prev >+functions, except that it looks for a specific window >+.I id >+and runs the specified >+.I command >+on it. The optional >+.I conditions >+are the same as for >+.BR Current . >+The second form of syntax retrieves the window id of the root >+window of the given >+.IR screen . >+If no >+.I screen >+is given, the current screen is assumed. The window indicated by >+.I id >+may belong to a window not managed by fvwm or even a window on a >+different screen. Although most commands can not operate on such >+windows, there are some exceptions, for example the >+.B WarpToWindow >+command. >+.EX >+WindowId 0x34567890 Raise >+WindowId root 1 WarpToWindow 50 50 >+WindowId $0 (Silly_Popup) Delete >+.EE >+Mostly this is useful for functions used with the >+.B WindowList >+built-in, or for selective processing of >+.B FvwmEvent >+calls (as in the last example). >+ >+ >+.SS MODULE COMMANDS >+ >+Fvwm maintains a database of module configuration lines in a form >+.EX >+.BI "*" "<ModuleName>" ": " "<Config-Resource>" >+.EE >+where >+.I "<ModuleName>" >+is either a real module name or an alias. >+ >+This database is initially filled from config file (or from >+output of >+.B \-cmd >+config command), and can be later modified either by user (via >+.BR FvwmCommand ) >+or by modules. >+ >+When modules are run, they read appropriate portion of database. >+(The concept of this database is similar to one used in X resource >+database). >+ >+Commands for manipulating module configuration database are >+described below. >+ >+.TP >+.BI "*" module_config_line >+Defines a module configuration. >+.I module_config_line >+consists of a module name (or a module alias) and a module >+resource line. The new syntax allows a delimiter, a colon and >+optional spaces, between the module name and the rest of the line, >+this is recommended to avoid conflicts. >+.EX >+*FvwmIconBox: MaxIconSize 48x48 >+*FvwmPager: WindowBorderWidth 1 >+*FvwmButtons-TopRight: Geometry 100x100-0+0 >+*FvwmButtons-Bottom: Geometry +0-0 >+.EE >+ >+.TP >+.BI "DestroyModuleConfig " module_config >+Deletes module configuration entries, so that new configuration >+lines may be entered instead. This also sometimes the only way to >+turn back some module settings, previously defined. This changes >+the way a module runs during a fvwm session without >+restarting. Wildcards can be used for portions of the name as >+well. >+ >+The new non-conflicting syntax allows a delimiter, a colon and >+optional spaces between the module name and the rest of the line. >+In this case a module name (or alias) can't have wildcards. >+.EX >+DestroyModuleConfig FvwmButtons* >+DestroyModuleConfig FvwmForm: Fore >+DestroyModuleConfig FvwmIconBox: Max* >+.EE >+ >+.TP >+.BI "KillModule " modulename " [" modulealias ] >+Causes the module which was invoked with name >+.I modulename >+to be killed. The name may include wildcards. If >+.I modulealias >+is given, only modules started with the given alias are killed. >+.EX >+KillModule FvwmPager # kill all pagers >+ >+Module FvwmEvent SoundEvent >+KillModule FvwmEvent SoundEvent >+.EE >+ >+.TP >+.BI "Module " modulename " [" moduleparams ] >+Specifies a module with its optional parameters which should be >+spawned. Currently several modules, including >+.BR FvwmButtons ", " FvwmEvent ", " FvwmForm ", " FvwmGtk ", " >+.BR FvwmPager ", " FvwmScript >+support aliases. Aliases are useful if more than one instance of >+the module should be spawned. Aliases may be configured >+separately using >+.B * >+syntax described above. To start a module >+.B FvwmForm >+using an alias >+.IR MyForm , >+the following syntax may be used: >+.EX >+Module FvwmForm MyForm >+.EE >+ >+At the current time the available modules (included with fvwm) are >+.B FvwmAnimate >+(produces animation effects when a window is iconified or >+de-iconifed), >+.B FvwmAudio >+(makes sounds to go with window manager actions), >+.B FvwmAuto >+(an auto raise module), >+.B FvwmBacker >+(to change the background when you change desktops), >+.B FvwmBanner >+(to display a spiffy XPM), >+.B FvwmButtons >+(brings up a customizable tool bar), >+.B FvwmCommandS >+(a command server to use with shell's FvwmCommand client), >+.B FvwmConsole >+(to execute fvwm commands directly), >+.B FvwmCpp >+(to preprocess your >+.I .fvwm2rc >+with cpp), >+.B FvwmDebug >+(to help debug fvwm), >+.B FvwmDragWell >+(the place to drag&drop to), >+.B FvwmEvent >+(trigger various actions by events), >+.B FvwmForm >+(to bring up dialogs), >+.B FvwmGtk >+(to bring up GTK menus and dialogs), >+.B FvwmIconBox >+(like the mwm IconBox), >+.B FvwmIconMan >+(a flexible icon manager), >+.B FvwmIdent >+(to get window info), >+.B FvwmM4 >+(to preprocess your >+.I .fvwm2rc >+with m4), >+.B FvwmPager >+(a mini version of the desktop), >+.B FvwmSave >+(saves the desktop state in .xinitrc style), >+.B FvwmSaveDesk >+(saves the desktop state in fvwm commands), >+.B FvwmScript >+(another powerful dialog toolkit), >+.B FvwmScroll >+(puts scrollbars on any window), >+.B FvwmTaskBar >+(a Windows like task bar), >+.B FvwmTheme >+(manages colorsets, see below), >+.B FvwmWinList >+(a window list), >+.B FvwmWharf >+(an AfterStep like button bar). >+These modules have their own man pages. There may be other >+modules out on there as well. >+ >+Note, >+.B FvwmTheme >+is a special module which manages colorsets. Most of other modules >+and fvwm itself support colorsets and changing colors >+dynamically. Colorsets will probably be the only method to specify >+colors in the next stable fvwm release, and then the functionality >+of FvwmTheme will be moved to the core fvwm. >+ >+ >+Modules can be short lived transient programs or, like >+.BR FvwmButtons , >+can remain for the duration of the X session. Modules are >+terminated by the window manager prior to restarts and quits, if >+possible. See the introductory section on modules. The keyword >+.B Module >+may be omitted if >+.I modulename >+is distinct from all built-in and function names. >+ >+.TP >+.BI "ModulePath " path >+Specifies a colon separated list of directories in which to search >+for modules. To find a module, fvwm searches each directory in >+turn and uses the first file found. Directory names on the list >+do not need trailing slashes. >+ >+The >+.BI ModulePath >+may contain environment variables such as >+.IR $HOME " (or " ${HOME} ). >+Further, a '+' in the >+.I path >+is expanded to the previous value of the >+.IR path , >+allowing easy appending or prepending to the >+.IR path . >+ >+For example: >+.EX >+ModulePath ${HOME}/lib/fvwm/modules:+ >+.EE >+The directory containing the standard modules is available via the >+environment variable >+.IR $FVWM_MODULEDIR . >+ >+.TP >+.BI "ModuleSynchronous [" "Expect string" "] [" "Timeout secs" "] " modulename >+The >+.B ModuleSynchronous >+command is very similar to >+.BI Module . >+Fvwm stops processing any commands and user input until the module >+sends a string beginning with "NOP FINISHED STARTUP" back to fvwm. >+If the optional >+.I Timeout >+is given fvwm gives up if the module sent no input back to fvwm >+for >+.I secs >+seconds. If the >+.I Expect >+option is given, fvwm waits for the given >+.I string >+instead. >+.B ModuleSynchronous >+should only be used during fvwm startup to enforce the order in >+which modules are started. This command is intended for use with >+the >+.B FvwmTheme >+module since the configuration must be in place before any other >+modules are started. >+ >+Warning: It is quite easy to hang fvwm with this command, even if >+a timeout is given. Be extra careful choosing the string to wait >+for. Although all modules in the fvwm distribution send back the >+"NOP FINISHED STARTUP" string once they have properly started up, >+this may not be the case for third party modules. Moreover, you >+can try to escape from a locked >+.B ModuleSynchronous >+command by using the key sequence >+.SM Ctrl-Alt-Escape >+(see the >+.BR EscapeFunc ). >+ >+.TP >+.BI "ModuleTimeout " timeout >+Specifies how many seconds fvwm waits for a module to respond. If >+the module does not respond within the time limit then fvwm kills >+it. >+.I timeout >+must be greater than zero, or it is reset to the default value of >+30 seconds. >+ >+.TP >+.BI "SendToModule " "modulename string" >+Sends an arbitrary string (no quotes required) to all modules, >+whose alias or name matching >+.IR modulename , >+which may contain wildcards. This only makes sense if the module >+is set up to understand and deal with these strings though. Can be >+used for module to module communication, or implementation of more >+complex commands in modules. >+ >+ >+.SS QUIT, RESTART AND SESSION MANAGEMENT COMMANDS >+ >+.TP >+.BI "Quit" >+Exits fvwm, generally causing X to exit too. >+ >+.TP >+.BI "QuitScreen" >+Causes fvwm to stop managing the screen on which the command was >+issued. >+ >+.TP >+.BI "QuitSession" >+Causes a session manager (if any) to shutdown the session. This >+command does not work for xsm, it seems that xsm does not >+implement this functionality. Use Unix signals to manage xsm >+remotely. >+ >+.TP >+.BI "Restart [" window_manager " [" params "]]" >+Causes fvwm to restart itself if >+.I window_manager >+is left blank, or to switch to an alternate window manager (or >+other fvwm version) if >+.I window_manager >+is specified. If the window manager is not in your default search >+path, then you should use the full path name for >+.IR window_manager . >+ >+This command should not have a trailing ampersand. The command >+can have optional parameters with simple shell-like syntax. You >+can use >+.I ~ >+(is expanded to the user home directory) and environmental >+variables .IR $VAR " or " ${VAR} . Here are several examples: >+.EX >+Key F1 R N Restart >+Key F1 R N Restart fvwm2 -s >+Key F1 R N Restart ~/bin/fvwm2 -f $HOME/.fvwm/main >+Key F1 R N Restart fvwm1 -s -f .fvwm1rc >+Key F1 R N Restart xterm -n '"X console"' \\ >+ -T \\"X\\ console\\" -e fvwm1 -s >+.EE >+If you need a native restart, we suggest only to use >+.B Restart >+command without parameters unless there is a reason not to. If you >+use 'Restart fvwm2', all current command line arguments are lost, >+while on Restart without parameters or with --pass-args, they are >+preserved. Here are some cases when 'Restart fvwm2' causes >+troubles: >+.EX >+* running fvwm under a session manager >+* running fvwm with multi headed displays >+* having command line arguments, like -f themes-rc or -cmd >+* if the first fvwm2 in the $PATH is a different one >+.EE >+This is why we are issuing a warning on an old usage. If you >+really want to restart to fvwm2 with no additional arguments, you >+may get rid of this warning by using "Restart fvwm2 -s" or >+"Restart /full/path/fvwm2". >+ >+Note, currently with multi headed displays, restart of fvwms on >+different screens works independently. >+ >+.TP >+.BI "Restart " "--pass-args window_manager" >+The same as >+.B Restart >+without parameters but the name for the current window manager is >+replaced with the specified >+.I window_manager >+and original arguments are preserved. >+ >+This command is useful if you use initial arguments like >+.EX >+-cmd FvwmCpp >+.EE >+and want to switch to another fvwm version without losing the >+initial arguments. >+ >+.TP >+.BI "Restart " --dont-preserve-state " [" other-params "]" >+The same as >+.EX >+.BI "Restart [" other-params "]" >+.EE >+but it does not save any window states over the restart. >+ >+Without this option, >+.B Restart >+preserves most per-window state by writing it to a file named >+.I .fs-restart-$HOSTDISPLAY >+in the user's home directory. >+ >+.TP >+.BI "SaveSession" >+Causes a session manager (if any) to save the session. This >+command does not work for xsm, it seems that xsm does not >+implement this functionality. Use Unix signals to manage xsm >+remotely. >+ >+.TP >+.BI "SaveQuitSession" >+Causes a session manager (if any) to save and then shutdown the >+session. This command does not work for xsm, it seems that xsm >+does not implement this functionality. Use Unix signals to manage >+xsm remotely. >+ >+ >+.SS COLOR GRADIENTS >+ >+A color gradient is a background that changes its color gradually >+from one hue to a different one. Color gradients can be used by >+various commands and modules of fvwm. There are eight types of >+gradients: >+.B HGradient >+is a horizontal gradient, >+.B VGradient >+is vertical, >+.B DGradient >+is diagonal from top left to bottom right, >+.B BGradient >+is backwards diagonal from bottom left to top right, >+.B SGradient >+is concentric squares, >+.B CGradient >+is concentric circles, >+.B RGradient >+is a radar like pattern and >+.B YGradient >+is a Yin Yang style (but without the dots). >+ >+The color gradient syntax has two forms: >+ >+.TP >+.BI "?Gradient " "colors start-color end-color" >+This form specifies a linear gradient. The arguments denote the >+total number of >+.I colors >+to allocate (between 2 and 1000), the initial color and the final color. >+ >+Example: >+.EX >+TitleStyle VGradient 20 rgb:b8/ce/bc rgb:5b/85/d0 >+.EE >+ >+.TP >+.BI "?Gradient " "colors segments color length color" " [" "length color" "] ..." >+The second form specifies a nonlinear gradient. The arguments are: >+the total number of >+.I colors >+to allocate (between 2 and 1000), then the number of >+.IR segments . >+For each segment, specify the starting >+.IR color , >+a relative >+.IR length , >+then the ending color. Each subsequent segment begins with the >+second color of the last segment. The lengths may be any >+non-negative integers. The length of one segment divided by the >+sum of all segment's lengths is the fraction of the colors that >+are used for the segment. >+.in -2 >+ >+Examples: >+.EX >+MenuStyle * MenuFace DGradient \\ >+ 128 2 lightgrey 50 blue 50 white >+ >+# 20% gradient from red to blue, >+# 30% from blue to black, >+# 50% from black to grey >+MenuStyle * DGradient 100 3 Red 20 Blue 30 \\ >+ Black 50 Grey >+ >+# 50% from blue to green, then >+# 50% from yellow to red >+*FvwmTheme: Colorset 0 Blue Red HGradient \\ >+ 128 3 Blue 1000 Green 1 Yellow 1000 Red >+.EE >+ >+.SH ENVIRONMENT >+ >+.TP >+.I DISPLAY >+Fvwm starts on this display unless the >+.I -display >+option is given. >+.TP >+.I FVWM_MODULEDIR >+Set by fvwm to the directory containing the standard fvwm modules. >+.TP >+.I FVWM_USERDIR >+Used to determine the user's data directory for reading and >+sometimes writing personal files. If this variable is not already >+set, it is set by fvwm to $HOME/.fvwm, which is the default user's >+data directory. >+.TP >+.I SESSION_MANAGER >+Fvwm tries to contact this session manager. >+.TP >+.I SESSION_MANAGER_NAME >+This is used mainly to determine xsm running to work around its >+bug. If this variable is set to "xsm", DiscardCommand is set as >+xsm expects it and not as XSMP requires. If you run fvwm under >+xsm, you should set this variable to "xsm", otherwise old state >+files are not removed. >+.TP >+.I SM_SAVE_DIR >+If this is set, fvwm saves its session data in this >+directory. Otherwise it uses >+.IR $HOME . >+Note, the state files are named >+.I .fs-?????? >+and normally are removed automatically when not used anymore. >+ >+.SH AUTHORS >+ >+Robert Nation with help from many people, based on twm code, which >+was written by Tom LaStrange. After Robert Nation came Charles >+Hines, followed by Brady Montz. Currently fvwm is developed by a >+number of people on the fvwm-workers mailing list. >+ >+.SH COPYRIGHT >+ >+Fvwm and all the modules, scripts and other files coming with the >+distribution are subject to the GNU General Public License >+(GPL). Please refer to the >+.I COPYING >+file that came with fvwm for details. >+ >+.SH BUGS >+ >+As of fvwm version 2.4.0 there were exactly 71.8 unidentified >+bugs. Since then 22.825 bugs have been fixed. Assuming that there >+are at least 10 unidentified bugs for every identified one, that >+leaves us with 71.8 - 22.825 + 10 * 22.825 = 277.225 unidentified >+bugs. If we follow this to its logical conclusion we will have an >+infinite number of unidentified bugs before the number of bugs can >+start to diminish, at which point the program will be bug-free. >+Since this is a computer program infinity = 3.4028e+38 if you >+don't insist on double-precision. At the current rate of bug >+discovery we should expect to achieve this point in 4.27e+27 >+years. I guess we better plan on passing this thing on to our >+children... >+ >+Known bugs can be found in the fvwm bug tracking system >+(accessible from the fvwm home page) and in the >+.IR BUGS " or " TODO >+files in the distribution. These files are no longer maintained >+and may be out of date. >+ >+Bug reports can be sent to the fvwm-workers mailing list (see the >+.IR FAQ ) >+or reported through the bug tracking system. >+ >+The official fvwm homepage is >+.BR http://www.fvwm.org/ . >+ >+\" LocalWords: XTerm xterm rc fvwm Linux ICCCM CDE XView XINERAMA Xinerama >+\" LocalWords: EdgeResistance fvwm's IconBox MoveToScreen FvwmConsole >+\" LocalWords: FvwmCommand >diff -urN fvwm-2.4.7.orig/fvwm/screen.h fvwm-2.4.7/fvwm/screen.h >--- fvwm-2.4.7.orig/fvwm/screen.h Tue Oct 30 19:16:53 2001 >+++ fvwm-2.4.7/fvwm/screen.h Wed May 15 08:59:27 2002 >@@ -54,6 +54,13 @@ > #define COLORMAP_FOLLOWS_MOUSE 1 /* default */ > #define COLORMAP_FOLLOWS_FOCUS 2 > >+#ifdef FANCY_TITLEBARS >+#define TITLE_PADDING 5 >+enum tb_pixmap_enum {TBP_MAIN, TBP_LEFT_MAIN, TBP_RIGHT_MAIN, TBP_UNDER_TEXT, >+ TBP_LEFT_OF_TEXT, TBP_RIGHT_OF_TEXT, TBP_LEFT_END, >+ TBP_RIGHT_END, TBP_BUTTONS, TBP_LEFT_BUTTONS, >+ TBP_RIGHT_BUTTONS, NUM_TB_PIXMAPS}; >+#endif > > typedef struct > { >@@ -70,6 +77,9 @@ > GradientButton , > PixmapButton , > TiledPixmapButton , >+#ifdef FANCY_TITLEBARS >+ MultiPixmap , >+#endif > #ifdef MINI_ICONS > MiniIconButton , > #endif >@@ -123,6 +133,10 @@ > struct > { > Picture *p; >+#ifdef FANCY_TITLEBARS >+ Picture **multi_pixmaps; >+ short multi_stretch_flags; >+#endif > Pixel back; > struct > {
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=1147">View the attachment on a separate page</a>.</b>
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 2951
:
1107
|
1146
| 1147
