This version is out of date. Please see the latest version
Joseph M. Brenner, Latverian Consulting
doom@kzsu.stanford.edu
February 2, 1999 Revised: May 20, 1999
Previous Version
This is intended to help a new user customize the default windowing system of RedHat 5.x Linux distributions: Fvwm95/Another Level/fvwm2
I'm not sure how this is all going to fit into the existing structure of Tips and How-Tos, but I do know that there are gaps in that structure, and I'm offering up this web page as at least a temporary patch. It will probably eventually be a submission to the Linux Documentation Project (whenever I get around to learning how to use the SGMLtools package).
First of all, make sure you know what you have on your machine, and make sure that this web page (or anything you might be reading) matches what you've got. I'm writing this in January, 1999, and I've been experimenting with RedHat 5.2, where once you've logged in and you've run "startx" (if required by your configuration, alternately you may be kicked into X Windows automatically) you'll see a graphical user interface vaguely reminiscent of some popular software from the Beast of Redmond. This is the Fvwm95 style of AnotherLevel, which is built on top of the window manager called fvwm2, which works on top of X Windows, which works on top of the operating system that Torvalds built (yes, with more than a little help from Gnu, among others).
So start with the obvious:
Start -> About Fvwm
When I do this, I get a panel that tells me I'm using
"AnotherLevel - a FVWM2 configuration" "Copyright (C) 1997, Red Hat Software, Inc."Also note the line:
"Fcwm_Version=2.0.46, Options=SHAPE XPM M4"If this sounds more or less like what you've got, then maybe you can just follow the instructions here step-by-step and expect them to work.
Since we're talking about Linux here, there are many ways of customizing things, so let's narrow it down a bit. First of all, I'm talking about how to customize the behavior of a user account, without making any global changes to the system defaults. This rules out just editing the files in /etc/X11/AnotherLevel. Secondly, I'm interested here in how to get the default GUI (Fvwm95/Another Level) to work the way you want it to, and so for now I'm ignoring the more radical option of just changing to a different Another Level style (AfterStep, WindowMaker, or Lesstif WM) or of switching to a completely different window manager system (such as twm or vanilla fvwm2, or possibly now something like gnome/Enlightenment). And finally, I'm largely going to talk about just one technique that I've actually gotten to work, though there are probably other ways of doing it (certainly there are supposed to be).
My approach here is to clone the entire system configuration of Another Level, then get the user's account to run the clone rather than the system files. In my opinion, this has a number of advantages:
/usr/X11R6/bin/RunWMSince there seems to be some difference of opinion as to what the correct name of the .xinitrc file is, it is probably a wise move to create a series of symlinks to cover all of the possible alternate names of this file. So do this in a command shell:
cd ln -sf .xinitrc .Xclients ln -sf .xinitrc .xsession ln -sf .xinitrc .xsessionrc ln -sf .xinitrc .Xrc
This should do it:
cp -rf /etc/X11/AnotherLevel ~/.AnotherLevel
mv ~/AnotherLevel/fvwm2rc.m4 ~/.fvwm2rc.m4
define(`ANOTHERLEVEL', `/etc/X11/AnotherLevel')and change it to:
define(`ANOTHERLEVEL', `/home/USERNAME/.AnotherLevel')(where you need to replace USERNAME with your username, e.g. "doom" in my case... Note: you can not just use "~/" here).
You should now be in a position where the window manager for your account is running using the local configuration files, independent of the system configuration.
This is a relatively easy one.
Edit the file~/.AnotherLevel/decors/FVWM95Find the line:
define(`BG_COLOR', `cyan4')and change the color to something else, for example
define(`BG_COLOR', `"#2E0017"')Note that you need to add a set of double quotes if you want to use a numeric color designation like this.
If you prefer to use named colors, you can look them up in this file:
/usr/X11R6/lib/X11/rgb.txtBut, it's probably simplest to get a numeric color by doing a:
Start -> Preferences -> Background
This brings up a window that let's you dial up combinations
of red-green-blue values, and try them out. Note that on
the left the hexadecimal value of the color is displayed
(e.g. the default is #009191, which is evidentially "cyan4",
or as I think of it "ReallyUglyTurquoise". And no clearer proof
exists that hackers are unequipped for esthetic design).
Incidentally, I highly recommend working with low numbers, and therefore very dark colors. I find that the less light I have coming out of the screen, the longer I can stand to look at it.
This is also fairly simple: instead of using xsetroot as described above, you need to use xpmroot. However, this method requires that the graphic file should be in "Xpm" format, so if you have a gif or jpeg or something, you should convert it to xpm by using something like gimp.
Once that's done, edit the file
~/.AnotherLevel/fvwm2rc.init.m4Find the line:
AddToFunc "SetupFunction"
Note: if you've previously added a line like this here (as described above):
+ "I" Exec xsetroot -solid BG_COLORIt's important to comment it out now, by adding a leading "#" like so:
#+ "I" Exec xsetroot -solid BG_COLORAnd immediately after the AddToFunc "SetupFunction" line, insert the line:
+ "I" Exec xpmroot /home/USERNAME/.AnotherLevel/icons/niftytile.xpmwhere once again, your username should be inserted here for USERNAME, and "niftytile.xpm" should be the name of whatever pixmap file you're interested in using.
Obviously, I'm putting the xpm file in
/home/USERNAME/.AnotherLevel/icons/
So you're going to need to create that directory and move
the file there.
It would probably be more in the spirit of AnotherLevel (such as it is) to put this file name in a variable in ~/.AnotherLevel/decors/FVWM95, by doing something like
define(`BG_PIXMAP', `/home/USERNAME/.AnotherLevel/icons/niftytile.xpm')And then in ~/.AnotherLevel/fvwm2rc.init.m4 you'd do something like:
+ "I" Exec xpmroot BG_PIXMAPBut I never got this to work, so I went for the direct approach here.
There are a number of changes that you can make simply by uncommenting some lines already present in
~/.AnotherLevel/fvwm2rc.defines.m4
One of the more important ones, in my opinion, is to change the "autoraise" parameters so that you can Alt-Tab between windows in the manner that someone used to Brand Ecch software would expect. You may have noticed that when you do an Alt-Tab, the selected window changes (i.e. the "focus" moves), but the selected window is *not* brought up on top of the stack of windows. To get it to do this you need to turn on "AutoRaise". You can experiment with this by doing this:
Start -> Preferences -> AutoRaise -> 0 msTo make this change permanent, edit the file
~/.AnotherLevel/fvwm2rc.defines.m4First, I recommend finding these lines:
# AUTO_RAISE_SPEED is the time in ms before auto-raising a window with FvwmAuto define(`AUTO_RAISE_SPEED',200)and change the 200 to 0:
define(`AUTO_RAISE_SPEED',0)
Then find these lines immediately below:
# Uncomment USE_AUTO_RAISE turn turn on window autoraising by default #define(`USE_AUTO_RAISE')And uncomment the second line there (remove the #) so that it looks like:
define(`USE_AUTO_RAISE')
Incidentally, immediately following these lines, you'll see this stuff (which you can probably ignore):
# If defined, the focus follows the pointer. Otherwise focus is set by # clicking on a window. Undefined this implements "ClickToFocus". Please note # that AutoRaise does not work with ClickToFocus... #define(`FOCUS_FOLLOWS_POINTER')I find this completely baffling. As far as I can tell "AutoRaise" works fine with "ClickToFocus".
Note: if you're used to that other operating system, you probably expect that an Alt-Tab will take you back to the most recently used window. Instead, Alt-Tab in X Windows rotates through the other windows in a sequence that stays fixed, unless you do something to modify it (e.g. with the "Raise" command that you can access by clicking in the upper left corner). I don't know of any way to get the Alt-Tab sequence to be updated automatically in X (and my first guess is that this must be very difficult for some reason... SGI's Irix has this problem too).
Just as an example, suppose you always want to have an emacs window up and running when you start X windows (though the techniques here will work for, say, gimp, or any other program that you might use a lot).
(You might think that the solution is to just add a line to the .xinitrc file mentioned above. If you start the file with a "emacs &", won't that do the job? Yes and no. My experience is that this will not interact well with the Alt-Tab feature of AnotherLevel, I presume because the emacs process is being started before AnotherLevel kicks in. I recommend avoiding putting anything in your .xinitrc besides the RunWM line.)
The right way to do it is to add the command to start your emacs window to
~/.AnotherLevel/fvwm2rc.init.m4Find these lines:
# StartupFunction only gets run at Init, not at Restart. # It is run after SetupFunction, but before EndSetupFunction AddToFunc "StartupFunction" + "I" Exec XTERM +ut -geometry +PctOfScreenInPixelsX(15)+PctOfScreenInPixelsY(15)And insert this line immediately afterwards:
+ "I" Exec emacs
Study the comments closely here. You might think that it would be just as good to add this line to the EndSetupFunction or the SetupFunction, but the first time you do a
Start -> Exit Fvwm -> RestartYou'll see why this is a bad idea. You probably don't want to add another emacs window every time you feel like testing a change to these configuration files...
(By the way, you have to love logical UI design like this... you go to "Start" to find the "Exit", and then inside the "Exit" you find another "start".)
Fvwm and it's descendants have an interesting feature (though personally I've always found that things like this are of somewhat limited utility) where you have a larger virtual desktop that extends beyond the size of the screen. You can page around on this virtual desktop by clicking on the "Desk/Apps" thumbnail, which by default is stuck to the screen over in the lower right hand corner of the screen.
Perhaps unfortunately, there's another way of switching between these pages, which is by slamming your mouse pointer against the edge of the screen. Considering the fact that there's a taskbar at the bottom of the screen, it's easy to see that you have a situation where a new user is going to be constantly switching to another empty page located "below" the main one. Here's a way you can eliminate this "Hey where did everything go?" experience.
Edit the
~/.AnotherLevel/fvwm2rc.defines.m4file, Find the lines
# EDGE_SCROLL_RESISTANCE, EDGE_MOVE_RESISTANCE are numbers given to Fvwm's # EdgeResistance configuration command. See fvwm2(1) define(`EDGE_SCROLL_RESISTANCE',400) define(`EDGE_MOVE_RESISTANCE',40)And increase the the edge scroll resistance to 10000
define(`EDGE_SCROLL_RESISTANCE',10000)
What if you want to go all the way, and get rid of the "Desks/Apps" thumbnail in the lower right of your screen? This method is a little ugly, but it works:
Edit the
~/.AnotherLevel/fvwm2rc.init.m4Find the line:
AddToFunc "EndSetupFunction"And immediately afterwards, add this line:
+ "I" KillModule FvwmButtonsAnd now after you restart, those three thumbnail sized "undecorated" windows down on the lower right of the screen should be gone (Both the load monitor, and the "Desks/Apps" pager feature next to it.) As you can see, this is a bit of a hack... rather than figure out what runs this thing in the first place, I'm just automatically killing it after it starts.
AnotherLevel builds up the taskbar menus automatically using the program wmconfig (if you study ~/.AnotherLevel/fvwm2rc.menus.m4 you'll see that there's a section labeled # AUTOMATIC MENU generation that runs wmconfig automatically). The source files for this process are in the form of a text file database, where there is one file that describes each application. The global files are found in /etc/X11/wmconfig, but these can be over-ridden with personal copies located in ~/.wmconfig.
So, suppose you are offended by the sheer length of that bland marketing-speak name "Netscape Communicator". Here's a way to fix this problem:
Create a ~/.wmconfig directory:
cd mkdir .wmconfigCopy the netscape-communicator file to there:
cp /etc/X11/wmconfig/netscape-communicator ~/.wmconfigNow edit the file:
~/.wmconfig/netscape-communicatorand change the first three lines to something that seems appropriate, so that the file looks something like this:
netscape-communicator name "Mozilla" netscape-communicator description "A Moz' by Any Other Name" netscape-communicator group Games/Video netscape-communicator exec "/usr/bin/netscape-communicator"
Note: if your editor generates automatic backup files of any sort, it's important to clear them out of this ~/.wmconfig location. (This is a serious gotcha for emacs abusers such as myself...)
Now, if you do a
Start -> Exit Fvwm -> Restartyou should see that Mozilla appears under
Start -> Program -> Games -> VideoAnd "Netscape Communicator" no longer appears under
Start -> Program -> Networking
So the above example actually shows you how to do two things: (1) rename a command in the taskbar menus and (2) move a command to a different menu. Suppose you wanted to do a copy rather than a move, and you'd like to see the same command appear in two different places in the menu tree? Just make a copy of your ~/.wmconfig/netscape-communicator file named as something else, say ~/.wmconfig/netscape-commie. Now edit the ~/.wmconfig/netscape-commie file, and make two changes: (1) replace "netscape-communicator" to with "netscape-commie" and change the group line so that it points at the Networking menu again. The file should look like:
netscape-commie name "Mozilla" netscape-commie description "A Moz' by Any Other Name" netscape-commie group Networking netscape-commie exec "/usr/bin/netscape-communicator"Now if you do a restart, you should find that Mozilla appears in Games/Video and also in Networking.
There are a few things worth noticing about this. One is that the first field there (the "package" according to man wmconfig) is actually arbitrary. It might be thought of as a unique record ID used to bind together the lines in the file.
The other thing to realize is that the file name is arbitrary (only by convention is it the same as the package name), and what really counts is where the file is located. This is where that Gotcha comes from I mentioned above: personally, I use emacs for almost everything, and whenever you change a file with emacs, it creates a backup copy of the previous version, with a tilde appended to the file name (to make matters worse, I use Dired to see what's in a directory, with the "Omit" feature on by default, which hides the existence of the backup files). When I first tried the above exercise, I had a netscape-communicator file, and also a netscape-communicator~ file. Then wmconfig came along and read one file first, and then read the other, and since the "package" name was the same in both, the contents of the second file overrode the contents of the first. I was seeing a very peculiar behavior: I couldn't get it to take a change until I gave up on it and tried another change.
I'd just say RTFM, but the "the" in this famous saying implies that there's only *one* manual that you need to read. Fat chance, huh?
For a lot of customizations there isn't any substitute for understanding exactly how all this works, and to do that you probably need to read:
As you might guess, this can take some time.
Note: the above list shows the commands you use from a terminal window. Personally I prefer to work inside of emacs, so instead of doing an info bash I would do something like ESC x info RET m bash RET. And instead of a man bash, I would do an ESC x man RET.
Start -> Exit Fvwm -> Switch to... ->By default, you should have at least these three options:
Where the first is the default, which you're already running, the second is an open source version of the Motif Window Manager (often used on commercial Unix boxes) and the third is an imitation of the popular NeXtStep interface.
You can also install "WindowMaker" off of the Red Hat 5.2 disks, in which case it will also appear in this "Switch to..." menu. WindowMaker is another NeXtStep like interface, and may be the best of the available styles with Red Hat 5.2 (it looks nice out of the box, and the "tear-off" menus work pretty well).
It might help to know that when you execute the "Switch to..." command, you're changing the file:
~/.wm_styleBy default this consists of just the one line: Fvwm95. So if you switch to another window manager, and you can't figure out how to switch back, you can always just edit this one file to return things to normal.
Note: that if you use a parameter with RunWM in your .xinitrc file, e.g.
RunWM --Fvwm95this will forcibly set the .wm_style file to "Fvwm95", effectively overriding the Switch to... feature.)
If you've ever looked at the Preferences menu closely, you might be wondering what's so difficult about customizing AnotherLevel. Why not just use the command:
Start -> Preferences -> Save desktop to new.xinitrcThe answer is that it doesn't work at all. Give it a try, it certainly does create a "new.xinitrc" file that contains a few lines of stuff, but
You may read about some alternates strategies to customize AnotherLevel than the one presented above.
Rather than copy the whole AnotherLevel directory to your home directory, it is supposed to be possible to copy over only the ones that you're interested in modifying (renaming them with a dot prefix). I've tried this without any success, though it certainly looks like it should work. Possibly I haven't quite got the right incantations. See man AnotherLevel if you'd like more details.
Another intriguing possibility is to take one of the temporary files (named things like /tmp/fvwmrcc00392, where the number varies) and copy it to your home directory, renaming it as .fvwm2rc (though man fvwm2 hints that the correct configuration file name *might* differ). These /tmp/fvwmrccXXXX files are created after processing the source with m4 and wmconfig. In theory using one of these as a basis for customization will take you back to the good old days of just one single window manager configuration file to worry about, and I would bet X Windows would start a little faster, too. I haven't played with this approach, so I can't swear that it would work.
There are limits to how much basic Unix info I can cover in a brief web page like this, but it's come to my attention that some people are not born with an innate understanding of the "hidden files" hack built into Unix. This is all there is to it:
If a file or directory begins with a dot, you won't see it if you do a simple ls. Traditionally, dot prefixes are used for configuration files that the user isn't expected to want to bother with very much, so if you look at the files in your home directory, you won't see all of the files like .bashrc by default. You have to say that you want to see the hidden files, by doing something like ls -a. See man ls for more details.
If you have any comments on this web page, please send them to
doom@kzsu.stanford.edu