If your web browser formats this page incorrectly, try viewing the page source. In netscape 4, click the view menu, then click page source. CONFIGURATION xwindows configuration is divided into two parts: server and clients. Server configuration includes selecting a server program and setting display resolution, display frequency, amount of display memory, type of video card, mouse, etc. Usually you select the server program by making a link named 'X', where X is a link to the real server program, and then you do not specify a server program, so xwindows uses the default server program, which is X. The main server configuration file is usually XF86Config, in directory /etc or directory /etc/X11; there may be additional command line parameters in shell scripts which call the server (such as $HOME/.xserverrc); you might give additional command line parameters; command line parameter may override the defaults in XF86Config. Usually you use programs like XConfigurator or SuperProbe to make XF86Config for you. Clients configuration includes selecting a window manager program, selecting programs to start when xwindows starts, resources, and keymaps. Resources are settings and preferences for xwindows programs. Some computers have a clients configuration script, which loads resources and keymaps, starts some programs, then starts the window manager. Other computers start the window manager, and then the window manager loads resources and keymaps and starts programs according to the window manager configuration file. And some computers do both. Clients configuration is very complicated, and it depends on what window manager you use. STARTING We start xwindows with either xinit or xdm. xdm is for starting xwindows before we log in (xdm starts xwindows when the computer boots and keeps xwindows running until the computer is turned off; or else xdm starts xwindows when we enter the xwindows runlevel and keeps xwindows running until we change runlevels). xinit is for starting xwindows after we have logged in (any time other than when we boot or when we change runlevels). The difference is that xinit uses the configuration in $HOME; xdm does not know what $HOME is, so xdm logs you in first, then figures out what $HOME is, then uses the configuration in $HOME. Maybe xdm calls xinit. To start xwindows with a specific window manager, run xinit /usr/bin/window_manager. You need to use the full path because xinit assumes that if you give the path, it is a window manager, and if you do not give the path, it is an option. Sometimes you run a script or wrapper instead of the actual window manager, because some window managers are split into several parts, and the script starts all of the parts. startx is another way to run xinit. startx checks for $HOME/.xinitrc, $HOME/.xserverrc, /etc/X11/xinit/xinitrc, and /etc/X11/xinit/xserverrc; and runs xinit $clientargs -- $serverargs To make your own customized xwindows configuration for yourself, not for other users, create files in your home directory named .xserverrc, .xinitrc, .Xresources, and .Xmodmap. When you run 'startx', it should find and use your configuration files. If startx does not find and use your configuration files, start xwindows with 'xinit $HOME/.xinitrc -- $HOME/.xserverrc'. You probably want to create your own clients configuration but use the default server configuration; if so you can skip .xserverrc and start xwindows with 'xinit $HOME/.xinitrc'. Here is an example of an .xinitrc: #!/bin/sh xrdb -load $HOME/.Xresources xmodmap $HOME/.Xmodmap xsetroot -solid gray & xclock -g 50x50-0+0 -bw 0 & # displays a clock xload -g 50x50-50+0 -bw 0 & # displays a graph of how busy x is xbiff -geometry -430+5 & # watches for new mail xterm -g 80x24+0+0 & xterm -g 80x24+0-0 & exec twm # window manager Note that programs other than the window manager are started in the background. The window manager is started last with exec, in the foreground. xinit waits for the xinitrc process to finish, then kills the server and exits. Since we used exec, the .xinitrc process becomes the window manager process, and xinit waits for the window manager to exit; the result is that when you exit the window manager, you exit xwindows. You may be able to create a custom configuration file for your favorite window manager; this may be better than creating your own custom xwindows configuration. Actually, xinit does not do much; you might think you can skip xinit. The following example does not work, but it is supposed to do the exact same thing as the previous example: #!/bin/sh X & # run xserver in the background xserver_pid=$! # remember PID of xserver xrdb -load $HOME/.Xresources xmodmap $HOME/.Xmodmap xsetroot -solid gray & xclock -g 50x50-0+0 -bw 0 & # displays a clock xload -g 50x50-50+0 -bw 0 & # displays a graph of how busy x is xbiff -geometry -430+5 & # watches for new mail xterm -g 80x24+0+0 & xterm -g 80x24+0-0 & twm # run window manager in foreground kill $xserver_pid # after window manager exits, kill xserver All of the xclients will fail to connect to the server. Apparently xinit reconnects the standard input and output of the clients to the server or to a special terminal. If you can figure out how to do that, maybe you can make the previous example work. Also, you may need to be root to run the xserver. The following does not work: xinit /bin/sh -c 'xload&xclock&xterm&exec twm' Why not? That should be the same as an .xinitrc. FONTS *.bdf bitmap distribution format. I think xwindows cannot use bdf fonts, but xwindows includes a program named bdftopcf which converts bdf fonts to pcf *.spd speedo *.ttf truetype *.pfa adobe type1 font (*ascii*, for printing) *.pfb adobe type1 font (binary, compressed to save disk space) *.afm adobe font metric, information about type1 font, *.pfa and *.pfb files sometimes but not always have an *.afm file *.tfm information about adobe type1 font for use by TeX *.pcf portable compiled format, the normal xwindows font format *.pfm ? postscript? but smaller than *.afm *.gsf ghostscript font *.pfa files are in postscript format. The font file begins '%!PS'. There may be a line like /FontName /AriosoBold def This line gives the postscript name of the font, '/AriosoBold'; this data can be used to generate the Fontmap file. There are also lines like /FullName (Bitstream Charter Bold Italic) readonly def /FamilyName (Bitstream Charter) readonly def /Weight (Bold) readonly def /ItalicAngle 11.0000 def *.afm files include data similar to *.pfa files, like FontName Courier10PitchBT-Roman FullName Courier 10 Pitch FamilyName Courier 10 Pitch Weight Normal *.pfm files include some text strings in the middle, seperated by control-@, like @PostScript@Alexandria@Alexandria-BoldItalic@ *.pfb files include some text near the beginning, like the beginnings of *.pfa files, but the lines are seperated with control-m, like a mac text file, like this: ^M /FullName (Courier 10 Pitch) readonly def^M /FamilyName (Courier 10 Pitch) readonly def^M /Weight (Normal) readonly def^M /ItalicAngle 0 def^M and ^M/FontName /Courier10PitchBT-Roman def^M unix xwindows font names as given in fonts.dir files are like this: -foundry-family-weight-slant-setwidth-addstyle-pixel-point-resx-resy-spacing-width-charset-encoding The two main font directories are /usr/share/fonts and /usr/X11R6/lib/X11/fonts The xserver provides fonts to programs. Programs may also have their own fonts. The xserver fonts configuration is set in /etc/X11/XF86Config. Redhat 7.2 uses an xserver fonts configuration of FontPath "unix/:7100" which tells the xserver to use the xfs fontserver. redhat 7.2 uses an xfs fontserver configuration of catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/misc, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/X11R6/lib/X11/fonts/cyrillic, /usr/X11R6/lib/X11/fonts/CID, /usr/X11R6/lib/X11/fonts/local, /usr/X11R6/lib/X11/fonts/latin2/Type1, /usr/share/fonts/default/TrueType, /usr/share/fonts/default/Type1, /usr/share/AbiSuite/fonts, /usr/share/fonts/ja/TrueType fontfs bitstream fontastic version included with corel photopaint 9 from about year 2000 doc says use ftfi for interactive manual font installation. can use *.ttf, *.pfb (type1), and *.spd (speedo); maybe more. the wp fonts for fontastic install a config file named /etc/fontastic/config, which includes some explanation and appears to give a font path. So maybe we can install fonts automatically by adding fonts to the font path. But would the fonts be enabled or disabled? config file says catalogue = /usr/share/fonts/userfonts, /usr/share/fonts/wprequired port = 7102 If you try running mkfontdir in a directory containing windows *.ttf fonts and not containing a fonts.scale file, mkfontdir will not find any of the windows *.ttf fonts, and will not list the *.ttf fonts in the fonts.dir file. mkfontdir will not list *.ttf fonts unless mkfontdir is able to read font data from fonts.scale. Is there is a program which examinies windows *.ttf font files and guesses the xwindows font data, and puts the font data into fonts.scale so mkfontdir can find the fonts and xwindows can use the fonts? If we put a command like '(/usr/share/fonts/foo.ttf) findfont' in a postscript file, and run the postscript file through ghostscript with a command like 'gs foo.gs', then ghostscript displays many messages, including the font name, in the xterm window where we typed the gs command, while displaying the file in another xwindow. So ghostscript must be able to find the font name somewhere in the *.ttf file. So maybe we could extract font names from *.ttf files by making a script which creates a dummy postscript file, then runs it through ghostscript, and searches through the ghostscript output for the font name. Note this is using gs, not gv. Maybe we could redirect ghostscript output to nullpage so gs would not display the file in another xwindow, and we could run the script without running xwindows. I put a directory with windows *.ttf fonts in the font path. mkfontdir did not find any fonts. I think I deleted fonts.dir since fonts.dir did not list any fonts. One day I noticed that xwindows included the fonts from that directory. I checked, and some program had generated fonts.scale, encodings.dir, and fonts.dir. Was it the redhat 7.2 font server? Does xfs automatically add *.ttf fonts to fonts.scale and fonts.dir? The only other suspect is fontastic font server from corel photopaint, but it was probably not fontastic because that directory was not in the fontastic font path. Could it have been wine? I copied some *.ttf fonts to a temporary directory, with no font index files, added the temporary directory to the font path, and ran xfs font server. xfs did not create fonts.dir or any other font index files. xfs font server from redhat 7.2 from year 2002 can use gzipped fonts, provided that the font file name listed in fonts.dir includes the *.gz extension. *.ttf, *.gsf, and *.pfa font files shrink to about 60% of their former size when gzipped. *.pfb font files shrink very little and sometimes become larger when gzipped. Maybe the *.afm and *.pfm files can also be gzipped. But ghostscript cannot use gzipped font files, so if you want ghostscript and xwindows to share the same font files, do not gzip the font files. Ghostscript does not get fonts from the xserver. Ghostscript 6.51 from year 2001 gets fonts from the ghostscript path, using font index files named Fontmap. (If you run a program like gv or ghostview, fonts for the menus, dialogs, etc come from the xserver, but fonts for the main window come from ghostscript). Ghostscript 6.51 from year 2001 can use *.gsf, *.pfa, *.pfb, and *.ttf fonts. Since ghostscript can use many of the same fonts as xwindows, I think it would be a good idea to add the xwindows font directories to the ghostscript path. We can set the ghostscript path by setting environment parameter GS_LIB. However, if we use ghostscript to display something, ghostscript uses the user environment; if we use ghostscript to print something, ghostscript uses the lpd environment. I set environment parameter GS_LIB in my login scripts, and then ghostscript could find my xwindows fonts when displaying, but not when printing. I tried setting environment parameter GS_LIB in the boot script which starts lpd, but ghostscript still could not find my xwindows fonts when printing. In the wine documentation, it suggests the following for fonts.scale: arial.ttf -monotype-arial-medium-r-normal--0-0-0-0-p-0-iso8859-1 arialbd.ttf -monotype-arial-bold-r-normal--0-0-0-0-p-0-iso8859-1 arialbi.ttf -monotype-arial-bold-o-normal--0-0-0-0-p-0-iso8859-1 ariali.ttf -monotype-arial-medium-o-normal--0-0-0-0-p-0-iso8859-1 cour.ttf -monotype-courier-medium-r-normal--0-0-0-0-p-0-iso8859-1 courbd.ttf -monotype-courier-bold-r-normal--0-0-0-0-p-0-iso8859-1 courbi.ttf -monotype-courier-bold-o-normal--0-0-0-0-p-0-iso8859-1 couri.ttf -monotype-courier-medium-o-normal--0-0-0-0-p-0-iso8859-1 times.ttf -monotype-times-medium-r-normal--0-0-0-0-p-0-iso8859-1 timesbd.ttf -monotype-times-bold-r-normal--0-0-0-0-p-0-iso8859-1 timesbi.ttf -monotype-times-bold-i-normal--0-0-0-0-p-0-iso8859-1 timesi.ttf -monotype-times-medium-i-normal--0-0-0-0-p-0-iso8859-1 These were suggested for a specific font server. Probably it applies also to other font servers, but I found similar listings were created automatically, probably by redhat 7.2 xfs font server, so why bother creating these listings manually? If you want to put several collections of fonts with several fonts.scale files into one directory, you need to consolidate the fonts.scale files into a single fonts.scale file. mkfontdir tolerates some errors in fonts.scale, so we do not have to do a perfect job of creating fonts.scale. The first line is supposed to be a number, which is the number of fonts listed in fonts.scale. If the first line is not a number, mkfontdir ignores fonts.scale. If the number is too low, that has no effect, that is not a problem. If there is a line which is a number somewhere other than the beginning, the number and a space are prefixed onto the next line in fonts.dir, so the next line does not begin with the name of a font file, so the font in the next line is probably not useable. Thus we can automatically generate a consolidated fonts.scale file by renaming each fonts.scale file to fonts.scale.something_unique, writing a low number to the first line of fonts.scale, catting all the fonts.scale.* files to to fonts scale, while filtering out the first lines of all the fonts.scale.* files by deleting all lines which do not contain a space. echo 1 > ./fonts.scale cat ./fonts.scale.* | grep ' ' >> ./fonts.scale mkfontdir . On the other hand, since I found that fonts.scale was created automatically for *.ttf fonts, probably by redhat 7.2 xfs font server, so why bother fixing fonts.scale? Some programs, especially windows programs running under linux wine, do not like to have too many fonts. I know of no way to restrict the number of fonts to one program, without restricting the number of fonts to all programs. We can use xset to change the font path, so we can reduce the number of fonts by using xset to remove directories from the font path, then run our program, then use xset to restore the font path. However, that will affect every program which is running at that time. And if we are using a font server, xset does not remove directories from the font path of the font server. To reduce the number of fonts with a font server, we must either change the font server's configuration file and then tell the font server to reread the configuration; or else start an alternate font server with a smaller font path and then use xset to change to the alternate font server. I wonder if it is possible to create a program which intercepts calls from only one x program to the xserver, and passes most calls on to the real xserver, but filters responses to font calls, so that the x program sees only a limited number of fonts? Programs which use a lot of fonts, like word processors, usually do not get their fonts from xwindows. I guess the xwindows font functions are not suitable for use by word processors, I have no idea why. So around 2000, each program had its own font directory, and it was very difficult to configure different programs to share fonts. But kde programs all kept their fonts in /usr/share/fonts, so kde programs did share fonts. Then kde began using the fontconfig library, and other programs began using the fontconfig library, and it became easy for programs to share fonts. So by 2007 it was easy to add fonts to programs, you could either add the fonts to any subdirectory of /usr/share/fonts, because fontconfig always searched /usr/share/fonts, or you could put the fonts anywhere, and add the directory to /etc/fonts. Adding extra fonts to xwindows is almost useless, because xwindows fonts are only used for things like window titles, menus, and dialog boxes. Your extra xwindows fonts will not be used unless you reconfigure your window manager and change which fonts are used. If you want to add more fonts to your programs, you want to add the fonts to fontconfig, not to xwindows. using PIXEL MAPS Pixel maps are also called pixmaps, bitmaps, or icons. What is and is not a pixel map depends on what definition of pixel map you are using. All data must be converted to pixel maps in order to be displayed or printed. Thus any data which can be displayed or printed could be used as a pixel map. Usually pixels maps are small graphics in a simple format; text and large complex graphics are not usually considered pixel maps. xwindows servers do not provide pixel maps to programs. Each program has to find its own pixel maps. Various libraries provide pixel map functions. Most programs use pixel maps the same way, in the same pixel map formats, in same pixel map directories; because most programs use the same pixel map library functions, and because that makes it easier for one program to borrow pixel maps from another program. Pixel maps can be any size. The most common pixel map size is 32x32. But small pixel maps, like those used in menus, are usually 16x16. mini means 16x16. Some pixel maps are 48x48, 22x22, 64x64, etc. large probably means 48x48. Pixel maps are often stored in directories named icons. Sometimes there are different subdirectories for different size pixel maps. Pixel maps can be *.xpm, *.xbm, *.gif, *.png, *.tif, *.jpg, etc. *.xpm x pixel map, colors *.xbm x bit map, 2 colors, black and white *.gif can be transparent or not transparent; can be compressed or not compressed. Transparent gifs are a newer format; transparent means transparent is one of the colors, so that transparent pixels are the same color as the corresponding pixel of the previous layer or background. Compressed gifs are patented by Unisys; it is illegal to create compressed gifs without a license; you do not need a license to distribute or use compressed gifs. Sometimes pixel map file names include the size, like star32x32.xpm, star-32x32.xpm, or star_32x32.xpm; but usually the pixel map file name does not include the size. probably pixel maps named mini-*.xpm or *-mini.xpm are 16x16; probably pixel maps named *-32.xpm are 32x32, *-48.xpm are 48x48, *-64.xpm are 64x64, Pixel maps used by the apache web server are usually 20x22 and are *.gif format. Most window managers have an icon path, which is a list of directories in which the window manager searches for pixel maps. The icon path is usually used to find pixel maps to display on the window manager menus. The main kde pixel map directory in redhat 7.2 (year 2001) is /usr/share/icons. Most *.xpm pixel maps are in /usr/share/icons and /usr/share/icons/mini. Maybe pixel maps in /usr/share/icons are 32x32, and maybe pixel maps in /usr/share/icons/mini are 16x16. Most pixel maps are *.png, like /usr/share/icons/[something]/[size]/[something]/*.png, like /usr/share/icons/eclipse2/32x32/actions/mouse.png The main gnome pixel map directory in redhat 7.2 (year 2001) is /usr/share/pixmaps and subdirectories. Most pixel maps are *.png. Icewm from about year 2001 wants pixel maps in /usr/X11R6/lib/X11/icewm/icons (or in /etc/X11/icewm/icons or $HOME/.icewm/icons; or in icon search path defined in /usr/X11R6/lib/X11/icewm/preferences, /etc/X11/icewm/preferences, or $HOME/.icewm/preferences) The pixel maps included with icewm have named like [pixel map name]_[size].xpm, like pdf_16x16.xpm. I am not sure if icewm prefers the have the size included in the pixel map file name. When icewm displays the gnome menu, it usually displays the pixel maps correctly, so probably icewm does not require that the pixel map file name include the size. When icewm searches for a pixel map, icewm may try adding the size to the file name. Older and simpler xwindows window managers usually prefer *.xpm pixel maps. MENUS In 2001 gnome from redhat 7.2, the main programs menu is /usr/share/gnome/apps. Items in /etc/X11/applnk also appear on the main programs menu. Items in $HOME/.gnome/apps appear on the favorites menu. *.desktop and *.kdelnk items appear on menu; items with no extension are ignored. If a subdirectory of /etc/X11/applnk has the same name as a subdirectory of /usr/share/gnome/apps, then items in either subdirectory appear in the same submenu. .directory files in /usr/share/gnome/apps are used, but .directory files in /etc/X11/applnk are ignored. The main programs menu is displayed under programs on the main menu. We can right click on the main menu button, and select properties, and put the programs menu or the favorites menu on the main menu instead of into a submenu. gnome panel (button bar at bottom of display) /etc/gnome/panel-config/panel.d has data which tells gnome how to create the panel configuration when creating a user's gnome configuration panel configuration is in $HOME/.gnome/panel.d, probably one directory for each panel configuration, probably just default. You can add and remove stuff from panel by editing $HOME/.gnome/panel.d/default/Applet_Config, but it is easier to use gnome. To add something to the launcher, use menu panel, add to panel. To remove something from the panel, right click on it and select remove from panel. In 2001 KDE from redhat 7.2, main menu is $KDEDIR/share/applnk. Items in /etc/X11/applnk also appear on the main menu. *.desktop and *.kdelnk items appear on menu; items with no extension are ignored. If a subdirectory of /etc/X11/applnk has the same name as a subdirectory of $KDEDIR/share/applnk, then items in either subdirectory appear in the same submenu. .directory files in $KDEDIR/share/applnk are used, but .directory files in /etc/X11/applnk are ignored. If the same item appears in both $KDEDIR/share/applnk and /etc/X11/applnk, it only appears once in the kde menus $KDEDIR should be defined in the startup scripts. icewm 0.9.48 from 2001 has main menu in /usr/X11R6/lib/X11/icewm/menu (or $HOME/.icewm/menu or /etc/X11/icewm/menu) plus /etc/X11/applnk menu as redhat menu plus gnome menu as gnome menu. kde menu is NOT included. icewm menu entry: menu [name] folder { prog [name] [icon name] [command] } command may include spaces if name includes spaces, put name in double quotes icewm toolbar: /usr/X11R6/lib/X11/icewm/toolbar each line is prog [name] [icon] [command], like an icewm menu entry If you want to manually add programs to the menu, you should add the programs to the menu in /etc/X11/applnk, so the the programs will appear on kde, gnome, and icewm menus. Each file is a menu item. Each directory is a submenu. Each menu item file is like this: [Desktop Entry] Name=Gaim Comment=Client for AOL IM Exec=gaim Icon=gaim.xpm Terminal=0 Type=Application MimeType=image/gif;text/plain;text/x-makefile; The first line, '[Desktop Entry]', is probably not important, but all menu item files seem to have it. Some menu item files have [KDE Desktop Entry] instead of [Desktop Entry]. Name is the name which is displayed on the menu. Comment is a longer, more descriptive name which is displayed if you pause the mouse over that item on the menu. Exec is the command to run when the menu item is selected. Sometimes there are options, as in 'Exec=kedit -caption "%c" %i %m %u'. '%f' probably means a file name. Sometimes the command ends in '&', which is probably supposed to make the command run in the background, which is probably not needed because commands are probably always run in the background. Icon is the pixel map to display on the menu. If the pixel map file is not in the icon path, give the full path of the pixel map file. Terminal=0 means the program is an xwindows program and does not need to be run in an xterm. Terminal=1 means the program is not an xwindows program and needs to be run in an xterm. If terminal is not specified, terminal=0 is assumed. I do not know what Type=Application means. Programs seem to run fine if I leave that line out. Type=Directory is used in .directory files, but that seems redundant because directories are obviously directories. Type=MimeType is used in /usr/share/mimelnk files (which are not menu items, but use the same format as menu items), but that also seems obvious. I am not sure what mimetype is for. There can also be comment lines beginning with '#'. The only things we really need are name and exec. This format is used for both gnome and kde menus. I do not like default menu arrangement in redhat 7.2. Why have a submenu named applications? Isn't every program an application? Multimedia is too vague, and most programs on the multimedia submenu are sound programs, which are single medium, not multi-media. I think utilities means programs like tar, gzip, and grep which are noninteractive; utilities need to be run from an xterm because you need to type the appropriate options; therefore it makes no sense to put utilities on the menu, so why have a utilities submenu? I think a good menu arrangement would be: text editors, email clients, file managers, games, graphics, irc/mud/icq/im, programming, sound, spreadsheets and databases, system administration, video, web browsers and editors, word processing. My scheme sorts programs according to what type of data is processed by the program; thus a program for displaying but not editing microsoft word or adobe pdf files would be considered a word processor, since it displays data created by a word processor; the sound submenu would include sound recorders, sound editors, and sound players. Games could be subdivided into strategy games (like solitaire, minesweeper, mahjong, chess), skill games (like asteroids, breakout), complex games (like doom), and silly computer tricks (like the cockroaches that hide under windows, or the cat that chases the mouse).