Guidelines for Writing FVWM Configuration Files

[mimosinnet]

The FVWM configuration file can be written in many different ways, and all them may equally work. Nevertheless, there are configuration files better written, and this is not transparent when one first gets to work with FVWM.

I have just started with FVWM, and here there are some rules that I think could be considered good practice (please, correct if I am wrong, and I apologise if this is too obvious). I would appreciate if you could add your criteria and argumentation as to help the writing of FVWM configuration files (or links mentioning it).

1.- Make your configuration modular. Split up your configuration into small files read by the config file.
For example, my config file reads the following files:

[code]Read FvwmBacker
Read colors
Read style
Read decor
Read keys
Read mouse
Read menus
Read pager

Read buttons[/code]

To change the mouse mouse bindings you only need to look at a few lines instead of going through the whole of the configuration file. It is also easier to activate or deactivate parts of your desktop by adding # to the beginning of the Read section (in the example FvwmButtons is deactivated).

2.- Keep style definition together. The command style sets the attributes of windows containing applications or FVWM modules (like FvwmButtons, Menus,…). Having all style definitions together allows (a) to have an overview of window senttings and change them easily by copy/paste (b) see on a single view that window names are different.

3.- Prefix your Module Alias with the name of the module. This is taken from Nick Fortune in this post. If you have Net as your FvwmButtons alias, it is likely that some menu or application end up with the same name. You can use FvwmButtons-Net instead to make sure you have an unique name.

4.- Define the module before you start it. This is taken from Thomas Adam in this post. The idea is that the following configurations will both work:

DestroyModuleConfig Confi:* Module FvwmButtons Confi *Confi: ... *Confi: ....

DestroyModuleConfig Confi:* *Confi: ... *Confi: .... Module FvwmButtons Confi
Nevertheless, the second is common sense as you first define the module and call it afterwards.

5.- Use the Destroy module/menu/function definition before you start defining it. Quoting Thomas Adam:

They’re useful in clearing any previous definitions for the named menu/function/etc. Without them, AddTo{Func,Menu} are cumulative in that they’ll define (if none exists) and then continually add to the definition of the menu or function they’re defining. In most circumstances this is fine, although imagine what happens when a file is read from within FVWM (during its lifetime) – if a Destroy{Menu,Func} command did not exist, any subsequent AddTo{Func,Menu} commands would append to the definition, possibly tainting or giving incorrect results.

[thomasadam]

@mimosinnet

To change the mouse mouse bindings you only need to look at a few lines instead of going through the whole of the configuration file. It is also easier to activate or deactivate parts of your desktop by adding # to the beginning of the Read section (in the example FvwmButtons is deactivated).

This is simply a matter of personal taste. There’s no technical merit to having it split up. I prefer everything in one file since I can then see:

• Where and how everything gets loaded.
• I don’t have to worry about missing a file if I cp my configuration elsewhere.
• Tracking down issues during during startup is a nightmare having to trace through which file is read when, especially if one of those files has a destructive command in it, such as a Style command that overrides something else.

See: fvwmwiki.bu-web.de/FvwmFileStruc … uration%29

@mimosinnet

2.- Keep style definition together. The command style sets the attributes of windows containing applications or FVWM modules (like FvwmButtons, Menus,…). Having all style definitions together allows (a) to have an overview of window senttings and change them easily by copy/paste (b) see on a single view that window names are different.

Hmm. Again, this isn’t the real reason, see: linuxgazette.net/127/adam.html

Essentially, as with everything else you’ve alluded to, the ordering of your config file matters.

– Thomas Adam