xfwm(3.0) xfwm(3.0) NAME xfwm - XFce Window Manager SYNOPSIS xfwm [ options ] DESCRIPTION xfwm is a window manager for X11. It is intially based on fvwm2 from Robert Nation, and fvwm was itself a derivated of twm, redesigned to minimize memory consumption, provide a 3-D look(1,8,3 Search::Dict) to window frames, and provide a simple virtual(5,8) desktop. COPYRIGHTS Since xfwm and fvwm are derived from twm code it shares twm's copy- rights. Since nearly every line of twm code has been changed, the twm copyright has been removed from most of the individual code files. xfwm's copyright is considered to be the same as twm's. twm is copyright 1988 by Evans and Sutherland Computer Corporation, Salt Lake City, Utah, and 1989 by the Massachusetts Institute of Tech- nology, Cambridge, Massachusetts, All rights reserved. fvwm is also copyright 1993 and 1994 by Robert Nation. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that the above copyright notice appear in(1,8) all copies and that both that copyright notice and this permission notice appear in(1,8) sup- porting documentation, and that the names of Evans & Sutherland and M.I.T. not be used in(1,8) advertising in(1,8) publicity pertaining to distribu- tion of the software without specific, written prior permission. ROBERT NATION, CHARLES HINES, EVANS & SUTHERLAND AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WAR- RANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL EVANS & SUTHERLAND OR M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUEN- TIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TOR- TUOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFOR- MANCE OF THIS SOFTWARE. THE VIRTUAL DESKTOP xfwm provides multiple virtual(5,8) desktops for users(1,5) who wish to use them. Several distinct desktops can be accessed (concept: one desktop for each project, or one desktop for each application, when view applica- tions are distinct). "Sticky" windows are windows which transcend the virtual(5,8) 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(3,n) desired. Window geometries are specified relative to the current viewport. That is: xterm -geometry +0+0 will always show up in(1,8) the upper-left hand corner of the visible por- tion of the screen. It is permissible to specify geometries which place windows on the virtual(5,8) desktop, but off the screen. For example, if(3,n) the visible screen is 1000 by 1000 pixels, and the desktop size is 3x3, and the current viewport is at the upper left hand corner of the desktop, then invoking: xterm -geometry +1000+1000 will place the window just off of the lower right hand corner of the screen. Some applications that understand standard Xt command line arguments and X resources, like xterm and xfontsel, allow the user to specify the start-up desk on the command line: xterm -xrm "*Desk:1" will start an xterm on desk number 1. Not all applications understand this option, however. You could achieve the same result with the following line in(1,8) your .Xde- faults file: XTerm*Desk: 1 INITIALIZATION During initialization, xfwm will search for a configuration file(1,n) which describes key and button bindings, and a few other things. The format of these files will be described later. First, xfwm will search for a file(1,n) named(5,8) .xfwmrc in(1,8) the users(1,5) home directory. If this file(1,n) is not present, xfwm will still work, but without some nice(1,2) user friendly definitions. xfwm automatically starts up xfce (The panel(1,3x,3x bottom_panel)), xfbd (the Backdrop man- ager), xfmouse (mouse settings) and xfsound (sound). xfwm will set(7,n,1 builtins) two environment variables which will be inherited by its children. These are $DISPLAY which describes the display on which xfwm is running. $DISPLAY may be unix:0.0 or :0.0, which doesn't work too well when passed through rsh to another machine, so $HOSTDISPLAY will also be set(7,n,1 builtins) and will use a network-ready description of the display. $HOSTDISPLAY will always use the TCP/IP transport protocol (even for a local connection) so $DISPLAY should be used for local connections, as it may use Unix-domain sockets, which are faster. xfwm has a two special functions for initialization: InitFunction and RestartFunction, which are executed during Initialization and Restarts (respectively). These may be customized in(1,8) the user's rc file(1,n) via the AddToFunc facility (described later) to start up modules, xterms, or whatever you'd like have started by wm. xfwm also has a special exit(3,n,1 builtins) function: ExitFunction, executed when exiting or restarting before actually quitting or anything else. It could be used to explicitly kill(1,2,1 builtins) modules, etc. MODULES A module is a separate program which runs as a separate Unix process but transmits commands to xfwm to execute. Users can write(1,2) their own modules to do any weird or bizarre manipulations without bloating or affecting the integrity of xfwm itself. Modules MUST be spawned by xfwm so that it can set(7,n,1 builtins) up two pipes for xfwm and the module to communicate with. The pipes will already be open(2,3,n) for the module when it starts and the file(1,n) descriptors for the pipes are provided as command line arguments. Modules can be spawned during xfwm at any time(1,2,n) during the X session by use of the Module built-in command. Modules can exist for the duration of the X session, or can perform a single task and exit. If the module is still active when xfwm is told to quit, then xfwm will close(2,7,n) the communication pipes and wait to receive a SIGCHLD from the module, indicating that it has detected the pipe(2,8) closure and has exited. If modules fail to detect the pipe(2,8) closure xfwm will exit(3,n,1 builtins) after approxi- mately 30 seconds anyway. The number of simultaneously executing mod- ules is limited by the operating system's maximum number of simultane- ously open(2,3,n) files, usually between 60 and 256. Modules simply transmit text commands to the xfwm built-in command engine. Text commands are formatted just as in(1,8) the case of a mouse binding in(1,8) the .xfwmrc setup(2,8) file. Certain auxiliary information is also transmitted, as in(1,8) the sample module xfwmButtons. The xfwmButtons module is documented in(1,8) its own man(1,5,7) page. ICCCM COMPLIANCE xfwm attempts to be ICCCM 1.1 compliant. In addition, ICCCM states that it should be possible for applications to receive ANY keystroke, which is not consistent with the keyboard shortcut approach used in(1,8) xfwm and most other window managers. OPTIONS These are the command line options that are recognized by xfwm: -f config_file Causes xfwm to Read config_file instead of ".xfwmrc" as its ini- tialization file. This is equivalent to -cmd "Read con- fig_file". -cmd config_command Causes xfwm to use config_command instead of "Read .xfwmrc" as its initialization command. (Note that up to 10 -f and -cmd parameters can be given, and they are executed in(1,8) the order specified.) -d displayname Manage the display called "displayname" instead of the name obtained from the environment variable $DISPLAY. -s On a multi-screen display, run xfwm only on the screen named(5,8) in(1,8) the $DISPLAY environment variable or provided through the -d option. Normally, xfwm will attempt to start up on all screens of a multi-screen display. -version Print the version(1,3,5) of xfwm to stderr. -sync Force xfwm to run in(1,8) synchronized mode. This can drastically reduce graphics performances. -noxfce Avoid xfwm from staring the xfce panel. CONFIGURATION FILES The configuration file(1,n) is used to describe mouse and button bindings, colors, the virtual(5,8) display size, and related items. The initializa- tion configuration file(1,n) is typically called ".xfwmrc". By using the "Read" built-in, it is easy to read(2,n,1 builtins) in(1,8) new configuration files as you go. Lines beginning with '#' will be ignored by xfwm. Lines starting with '*' are expected to contain module configuration commands (rather than configuration commands for xfwm itself). xfwm makes no distinction between configuration commands and built-in commands, so anything mentioned in(1,8) the built-in commands section can be placed on a line by itself for xfwm to execute as it reads the con- figuration file(1,n), or it can be placed as an executable command in(1,8) a menu(3x,n,n tk_menuSetFocus) or bound to a mouse button or a keyboard key. It is left as an exer- cise for the user to decide which function make sense for initializa- tion and which ones make sense for run-time. BUILT IN FUNCTIONS xfwm supports a set(7,n,1 builtins) of built-in functions which can be bound to key- board or mouse buttons. If xfwm expects to find a built-in function in(1,8) a command, but fails, it will check to see if(3,n) the specified command should have been "Function (rest of command)" or "Module (rest of com- mand)". This allows complex functions or modules to be invoked in(1,8) a manner which is fairly transparent to the configuration file. Example: the .xfwmrc file(1,n) contains the line "HelpMe". xfwm will look(1,8,3 Search::Dict) for a built-in command called "HelpMe", and will fail. Next it will look(1,8,3 Search::Dict) for a user-defined complex function called "HelpMe". If no such user defined function exists, xfwm will try to execute a module called "HelpMe". DEFAULT VALUES Here come the default values. These values can be augmented by all user definitions thru .xfwmrc configuration file. XORValue 0 ModulePath $PATH DeskTopSize 1x1 MenuFont fixed IconFont fixed WindowFont fixed # Gradient title bar TitleStyle Active Gradient #c7686b #aeb2c3 TitleStyle Inactive Gradient #606060 #a0a0a0 # If Gradient consumes too much colors for your screen, try Solid #TitleStyle Active Solid #c7686b #TitleStyle Inactive Solid #606060 ActiveColor #ffffe0 #aeb2c3 InactiveColor #000000 #a0a0a0 MenoColor #000000 #aeb2c3 #ffffe0 #c7686b CursorColor red white AnimateWin On FocusMode ClickToFocus #FocusMode FollowMouse Style "*" Title, BorderWidth 5 Style "*" RandomPlacement, SmartPlacement Style "XFce*" Sticky Style "XFbd*" Sticky Style "Popup*" Sticky AddToMenu builtin_menu "Builtin Menu" Title + "Exit xfwm" Quit AddToFunc WindowListFunc "I" WindowId $0 Iconify -1 + "I" WindowId $0 Focus + "I" WindowId $0 Raise + "I" WindowId $0 WarpToWindow 5p 5p AddToFunc "InitFunction" + "I" Module xfce + "I" Desk 0 + "I" Exec xfbd -d AddToFunc "RestartFunction" + "I" Module xfce + "I" Desk 0 + "I" Exec xfbd -d Mouse 0 T A Move Mouse 0 1 A Close Mouse 0 2 A Maximize Mouse 0 4 A Iconify Mouse 0 FS A Resize Mouse 1 R A Popup builtin_menu Mouse 1 I A Iconify Mouse 2 I A Move Mouse 3 I A Move Mouse 3 R A WindowList SUPPLIED CONFIGURATION A default configuration file(1,n), xfwmrc, is supplied with the xfwm distri- bution. It is well commented and can be used as a source of examples for xfwm configuration. USE ON MULTI-SCREEN DISPLAYS If the -s command line argument is not given, xfwm will automatically start up on every screen on the specified display. After xfwm starts each screen is treated independently. Restarts of xfwm need to be per- formed separately on each screen. The use of EdgeScroll 0 0 is strongly recommended for multi-screen displays. You may need to quit on each screen to quit from the X session com- pletely. BUGS Bug reports can be sent to fourdan@xfce.org. AUTHOR xfwm is initially based on Fvwm2, deeply modified by Olivier Fourdan (fourdan@xfce.org) for XFce needs. Xfwm and Fvwm2 codes are now very different. Robert Nation with help from many people, based on twm code, which was written by Tom LaStrange. 3rd Berkeley Distribution 12-Jun-1999 xfwm(3.0)