Home Index Search Links About LF
[LinuxFocus Image]
[Navegation Bar]
News    Archives    Map 
[no author]
by Joel McCarty



Configuring X: What are all those dotfiles for anyway?



Learn how to configure your X window environment -- find out what all those dotfiles are for!

_________________ _________________ _________________



Here is something for new system administrators and stand alone users wondering how to achieve greater flexibility setting up customized X sessions for yourself and your users.

First, this article assumes The X Window System is already installed and is being started by the startx command (configuring X for multiple users via XDM will hopefully be the subject of a later article). Now lets outline the basic files we will cover and a brief synopsis of what they do...

xinitrc is a shell script passed to xinit via the startx command. This script commonly sets some global resources ( screen saver settings, keyboard definitions, etc). This is the file that glues the X startup processes together.

This is a dotfile in a users home directory that starts user specific clients as opposed to ones called by xinitrc.

This is a file containing widget definitions that override program defaults. This file is commonly used to specify font sizes, colors and general look and feel but can also be used to achieve some pretty spectacular graphic effects.

Now that we've seen the basic files involved, lets delve into their configuration..



After issuing the startx command, xinit ( which is responsible for the X startup process) evaluates either /etc/X11/xinit/xinitrc (global) or if it exists, ~/.xinitrc (local). If neither of these files exists the choice of configuration is left up to the xinit process (not a good thing). The xinitrc file (local having precedence over global) is a shell script that starts various X clients as specified and then uses exec to start the specified window manager.

The simplest xinitrc file might look something like this...

# /etc/X11/xinit/xinitrc
exec /usr/X11R6/bin/fvwm2
Now this file does nothing more than execute F(eeble) Virtual Window Manager 2 and no other clients. Not very useful, but nice if you want to hack a setup for a new window manager in a jiffy. Now things get more interesting when we add in some settings and start some additional clients that we want each time X starts...


   # fix that annoying backspace problem
   xmodmap -e "keycode 22=BackSpace"

   # set  background
   xsetroot -solid LightSlateGrey

   # screen saver after five minutes
   xset s 300

   # X clients to be started universally follow
   xterm -g 80x20+150+8 &        # starts a terminal window
   xterm -g 80x20+150+325 &      # starts a 2nd window below the first
   xload -g +4+0 &               # starts a cpu load meter
   xclock -g +815+0 -digital &   # starts a digital clock

   # Start Window Manager
   exec fvwm2

Screenshot of X session using this configuration

Now we have a file that fixes that annoying backspace problem ( in most cases) ,sets our numlock, gets rid of that annoying moire background and starts a couple of programs each time we start X.

A few things to remember here, a local file in the users home directory will always be used if it exists ( totally ignoring system wide settings). Also notice the -g options on most commands, this is the geometry option that is available for many X programs. When used the geometry options species size and location of a program as...

Length x Width+ X coordinate+ Y coordinate

Now the thing to watch here is that xterm (and most other terminal programs) specify length and width in terms of character widths and heights, most other programs use pixels for these values (so if your not careful you'll end up with some pretty small windows!) Finally, pay careful attention to the ampersand appended to the end of each command other than the window manager itself. These ampersands tell the programs to run in the background (else the next command won't start till the previous one cancels - and that does no good). So ONLY the Window Manager gets started in the foreground and takes all processes started via xinitrc with it when you quit X.

Now we have a fairly functional script that can be used globally or put in a users home if we want to customize clients for particular users (i.e. we might want to write specific scripts for each department so that an engineering department user gets a different X startup than say someone in accounting). While there are pretty interesting possibilites here we have under-utilized many of it's capacities. Note that this is a shell script, so we can call any normal commands we would normally use and have them executed. Lets now take a look at a final example that uses xmodmap and xrdb to merge a users personal configuration with the system wide xinitrc file freeing us from the task of crafting a xinitrc file in the home of those users needing customized options (note specific usage of Xclients and Xresources are covered in the following sections):


# define locations for global and local resources

# merge system and user Xdefaults and keyboard maps
        if [ -f $sysresources ];  then xrdb -merge $sysresources; fi
        if [ -f $sysmodmap ];     then xmodmap $sysmodmap; fi
        if [ -f $userresources ]; then xrdb -merge $userresources; fi
        if [ -f $usermodmap ];    then xmodmap $usermodmap; fi

# fix that annoying backspace problem
xmodmap -e "keycode 22=BackSpace"

# set  background
xsetroot -solid LightSlateGrey

# screen saver after five minutes
xset s 300

# check for ~/.Xclients and execute else execute system
# default clients ( local and global are NOT merged)
if [ -f $userclients ]; then
        exec $userclients

      # start some default clients
      xterm -g 80x20+150+8 &
      xterm -g 80x20+150+325 &
      xload -g +4+0 &
      xclock -g +815+0 -digital &
      # start window manager


Screenshot of X session using this configuration

Now here we have first loaded all system keyboard maps and program defaults (defined in .Xmodmap and .Xresources) and then load all user specific settings (located in their home directory). Next we add the additonal settings we want to load even if they don't exist in system or home settings (i.e. backspace fix and numlock status). Now we check to see if the user has Xclients defined in their home directory ( and load them if present) else we start some system wide settings (note, unlike the defaults and resources earlier this two lines are NOT merged). A point to mention here, if the user did not have any Xclients defined their X startup would look like our original screenshot as opposed to the one above ; therefore we have the ability to have both a system wide look and feel and highly customized environments from the same xinitrc. Finally, we check to see if our preferred window manager(s) is/are present else we rely on good olde' fvwm2 for a back-up ( if this is not loaded the system will load twm as a last resort). Now we have a setup that allows us to make wide scale customizations for our users individually by simply setting local files or system wide by modifiying the system wide files without ever modifing our script file again.

Lets look at some of the files we referenced is the preceeding examples...



The ~/.Xclients file contains user specific clients to be read in and executed at startup of a X session. The syntax of this file conforms to comprable statements in the xinitrc file. Below is the ~/.Xclients file loaded via xinitrc used in the previous screenshot .

        xv -rmode -noresetroot -quit /usr/local/backgrounds/slate.xpm &
        kfm &
        kcontrol -init &
        kbgndwm &
        krootwm &
        kpanel &
        kvt &
As you can see from the previous screen shot, Xclients can be used to develop customized environments while retaing a centralized xinitrc file. One thing to notice here, in the above .xinitrc no clients are launched from this file if ~/.Xclients is present. I use this setup so each user can start thier favorite window manager via Xclients. If you need system specific clients loaded universally load them before executing a users Xclients (if ~/.Xclients contains a window manager call). For those of you interested in my desktop configuration used in the last example check out KDE's home page . Version 3.0 Beta is just out and contains many nice GUI configuration tools.


Resources in X define settings for programs locally (~/.Xresources) or globally (/usr/X11R6/lib/X11/xinit/.Xresources). X programs are made up of widgets. Widgets are control elements thus, there are widgets for the font, scroll bars and background settings. Almost anything in an X program is a widget (and therefore customizable).

Widgets are usually hierarchical, i.e. inside a frame widget for a menu there might be several widgets for individual buttons. To fully specify changes for a specific widget it must be expressed as a path to the individual component, this path is the widget names in the hierarchy. As an example below are lines from my ~/.Xdefaults file that standardizes all my terminal windows.

XTerm*Font:           -misc-fixed-bold-r-normal-15-140-75-75-c-90-iso8859-1
XTerm*Background:     black
XTerm*Foreground:     cyan
XTerm*scrollBar:      true
XTerm*saveLines:      500
Xterm*VT100.geometry: 80x24
Note that wild cards are allowed in this file thus...

*Foreground: cyan
*Background: black

Will define a standard look and feel for all programs that don't otherwise have explicit Xdefault settings. If you're like me and want more flexibility than wild cards allow but, yet can't remember widget hierarchies to save your life... check out editres! editres is a GUI based configuration tool that lwill let you generate extremely custom settings without having to write an .Xdefaults file. Check out a shot of editres in action ! By know you should begin to realize that Xdefaults offers some exciting opportunities to create a common look and feel as well as create some heavily customized clients. Check out what Xdefaults did to this lowly xcalc . For a step by step tutorial on fully exploiting editres' capabilities visit Isolation's X tips page.

Well that's about it for this month. I hope by now you see that X can be as standardized or customized as you wish without having to spend hours rewritng scripts for each new user. Next issue ( editor at large - Miguel A .Sepulveda - willing ) we'll take a look how to have multiple X logons on the same workstation using the X Display Manager. If you have any questions or comments feel free to drop me a line . Till next time...

For more information:

Webpages maintained by the LinuxFocus Editor team
© Joel McCarty, FDL
Translation information:
en --> -- : Joel McCarty <jmccarty(at)theshop.net>

2002-11-02, generated by lfparser version 2.34