Seth Woolley's Man Viewer

xfwm(1) - xfwm - XFce Window Manager - man 1 xfwm

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

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)

References for this manual (incoming links)