Basic fvwm Configuration
This article is primarily intended for, and dedicated to, all the novices and newcomers who have joined the worldwide community of Linux users. Welcome aboard! This article will attempt to introduce you to one of the most versatile and popular X-Windows managers: fvwm (which, I've been told, originally stood for “Frugal Virtual Window Manager”). Its well-deserved popularity is based, among other things, on its relatively parsimonious memory consumption, an extensively customizable 3 Motif-ish appearance, a virtual desktop, and the ability to extend functionality through the use of modules.
Before we begin, let me state a couple of presuppositions:
1. You've installed X-Windows and the fvwm window manager and have them working, and
2. You're willing to tinker a bit.
If this is you, keep reading!
First, some background: the concept of a window manager is, in essence, a rather simple one. X-Windows itself oversees certain rudimentary tasks such as managing the display hardware (monitor, keyboard, and mouse), handling mouse and keyboard events, and creating the windows which appear on the display. Just exactly how windows appear and behave is left up to the window manager. Window managers, such as fvwm, control how you interact with programs by providing decorative window frames, window controls, menus, virtual desktops, and so forth. Change to a different window manager and you can create a completely different look and feel even though the programs which run under them are identical.
fvwm was developed by Robert Nation as a derivative of one of the original MIT window managers, twm (the Tabbed Window Manager, which started life as Tom's Window Manager in honor of its author, Tom LaStrange). fvwm is currently maintained by Chuck Hines. The latest official release is fvwm-1.24r, although a beta version—pre2.0pl40 (as of mid-December 1995)--is currently available as well. These can be found at: ftp://sunsite.unc.edu/pub/Linux/X11/window-managers/ ftp://ftp.hpc.uh.edu/pub/fvwm/ ftp://ftp.x.org/contrib/
In addition, there are a number of excellent WWW pages dedicated to fvwm which provide a wealth of information, screen shots, and sample .fvwmrc configuration files. These include:
T.J. Kelly's The fvwm Home Page: www.cs.hmc.edu/~tkelly/docs/proj/fvwm.html
Todd Postma's fvwm Info: http://xenon.chem.uidaho.edu/~fvwm/
Jens Frank's fvwm Documentation: namu19.gwdg.de/fvwm/fvwm.html
Erik Kahler's fvwm Home Page: mars.superlink.net/user/ekahler/fvwm.html
At this point it's probably worth mentioning that if you're serious about customizing fvwm, it's a good idea to get the sources even if you don't intend to compile your own version. Why? Some Linux distributions do not include full documentation for every program. Getting the sources for fvwm ensures that you'll have the complete documentation, including manual pages for the various fvwm modules. Also, if you do choose to compile fvwm yourself, you can determine which features you wish to include.
Some of the basics we'll try to cover include:
1. Managing configuration files
2. Starting programs at load up
3. Adding items to the fvwm popup menus
4. Color customization
Keep in mind that the information presented here is intended to be used as a primer. I'd recommend skimming through the manual pages for fvwm in addition to reading this article. The definitive source of information is the manual page and documentation that comes with the program source distribution.
The first thing that you'll need to know about fvwm is where the configuration file is found. When fvwm starts, it first looks for .fvwmrc in your home directory. For example, if your username is johndoe, fvwm looks for the file /home/johndoe/.fvwmrc. If this file is absent it then looks for the system-wide configuration file /usr/lib/X11/fvwm/system.fvwmrc. If neither of these files are present, it simply exits.
One of the first things you'll want to do is make a copy of the default system-wide configuration file and put it in your home directory:
$ cp /usr/lib/X11/fvwm/system.fvwmrc ~/.fvwmrc
Be sure to copy this to ~/.fvwmrc and not ~/system.fvwmrc. Creating a copy of the file in your home directory is a good idea for a couple reasons:
1. If your .fvwmrc file gets corrupted, fvwm will fall back to using the system-wide configuration file.
2. If ~/.fvwmrc inadvertently gets deleted, you can use the system.fvwmrc file to re-create it.
3. On a multi-user system, it allows each user to customize her/his own .fvwmrc file.
The other issue to think about at the outset is sequential customizations. Chances are, over the course of several weeks or months, you'll make numerous small and large changes to the config file as you get fvwm customized to work the way you want it. What happens when you accidently overwrite or delete system.fvwmrc or your .fvwmrc? Serious bummer.
Managing system configuration files is important for anyone who is running, and likely administering, his own Linux system. It is wise to have a well-thought-out plan for how changes are implemented and changes tracked. Never do what you cannot undo. fvwm uses a single configuration file, making this a fairly simple task. Here are a few suggestions.
Before making any changes in a default configuration file, make a backup of it and give it a distinctive suffix, such as .dist. For example, before you edit the system.fvwmrc file for the first time, you'd make a copy of it by:
# cp system.fvwmrc system.fvwmrc.dist
The .dist suffix alerts you to the fact that this is an original file from the distribution. To further safeguard it, you should copy this to a directory owned by root (the superuser) and set the permissions on that directory to read and execute only, except for root. To do this, you could, for example, make a directory in your /etc or /usr/local directory called backups/ and then copy all default config files to this directory.
To do this, log in as root and enter:
# mkdir /etc/backups # chmod 755 /etc/backups
Setting the directory permissions, as root, to 755 allows root full read, write, and execute permissions, while preventing write permissions for everyone else. With read and execute permissions, users may change to the directory and do a file listing but cannot (since they don't have write permission to that directory) delete a file.
After you've created a backup directory and set the appropriate permissions you should, as root, make backup copies of important configuration files with the .dist suffix. You can also set the permissions for each file to read-only by:
# chmod 744 /etc/backups/system.fvwmrc.dist
This limits permissions on the file to read only for all users except root. Making backups of default configuration files is helpful only if it actually works. Obviously, you'll want to make a backup copy of a working configuration file. This, however, still doesn't address the question of what to do about keeping track of each of your changes. Here are a few suggestions.
1. After you have modified a configuration file, and ensured that it works correctly, make a copy of it and number each file consecutively such as:
fvwmrc.01 fvwmrc.02 fvwmrc.03 ...
Comments can be added by starting a line with the # (hash) character and should probably include the date and what modifications were made. If space is a problem, you can compress all the files you are not currently using.
2. Use RCS, the “Revision Control System”, to keep track of your changes. Before you make any changes to the file, run the RCS check-in program:
$ ci -l .fvwmrc
It will ask you for a description of the file; type:
fvwm configuration file .
The . on a line by itself finishes the description.
Then, every time you make a change to the file, run the same command. It will ask you for a description of the change you just made; type something like:
Added Calculator, xjed, and Emacs to the "Application" pop-up menu. .
so that you can find this change later.
RCS keeps track of all the changes you have made to .fvwmrc in a file called “.fvwmrc,v”. Instead of storing a complete copy of each new version of the file, it stores only the changes you have made, plus the latest version of the file.
How do you find the change later? The command line
$ rlog .fvwmrc | less
will give you a history of all the changes you have made. Each change has a revision number, starting at 1.1.
If you want to compare the current copy of the file with the version you previously checked in, use this command:
$ rcsdiff -u .fvwmrc | less
You can retrieve any version of the file you want (overwriting the current version) with
$ co -rrevision .fvwmrc
If you want more information on how to use RCS, it is available with:
$ man rcsintro
which provides a good overview of the concepts and commands you'll need to know. [Linux Journal also published an overview of RCS in issue 10, page 36—ED]
Using the RCS system is only slightly more complex a method of version control than simply making copies of every modified file. However, the basics are easily mastered and can be used for any file—programming project, article, term paper, etc.—that is undergoing sequential revision.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- Purism Librem 13 Review