fvwmwiki/ ConfigsGeneral/ filestructure

Filestructure

  1. Introduction (and a little bit of history)
  2. FVWM 2.X.Y and beyond
    1. The Single-file approach
      1. Multi-file approach
    2. Is there a "better" approach?

Introduction (and a little bit of history)

FVWM's configuration file has evolved since FVWM was conceived. Back in the 1.24.X days of FVWM, the order of its config file was important. FVWM1 expected certain features to be in place. The syntax was radically different as well. For example, Style lines had to have the name of the window/class/resource quoted as in:

Style "myApplication" Icon /some/icon/name.xpm

In the same way, the declaration of Functions was quite specific:

Function "Some-Function"
    Exec "I" some_program &
    Exec "I" some_other_program &
EndFunction

Thankfully though things have moved on since then, in that such stringent quoting and ordering rules have been resolved.

FVWM 2.X.Y and beyond

The Single-file approach

Since FVWM2, the way the config file for FVWM is structured, is completely down to the user. One approach is to lump everything in one file. This approach tends to be the most common -- perhaps a hangover effect from the old FVWM 1.X days (happy days!). The main approach here though is that it makes distribution slightly easier from one machine to another, or to others'.

A typical structure for this sort of file is:

But that is just one possibility, you can shove FVWM commands wherever you like, and although the order doesn't matter as to where each compoent goes, the sub-ordering of them does. So for instance:

  1. Any environment variables via the use of ''SetEnv'' '''must be declared at the top of your file, since the order the commands are listed within the .fvwm2rc file is the order they're processed in. So anything depending on these environment variables present, must appear after them.

  2. The same principle applies for ''ImagePath'' from 1., above.

  3. The sub-ordering of Styles is important. styles

Multi-file approach

Conversely to the single-file approach, the multi-file approach advocates the use of modualarity to the way one's FVWM setup is produced. The advantage of this is that each file will only ever house a limited set of commands, and will hold a logical grouping of commands.

As GeneralConfigGuideLines explains, FVWM looks for its files in ~/.fvwm -- so in that way one can separate out into different files what functionality is needed and then just call them from ~/.fvwm/config. As with the structure above you might decide to do (with file names in brackets):

In that way, the only thing you would need to add to ~/.fvwm/.fvwm2rc or ~/.fvwm/config (see ["Configuration/GeneralConfigGuideLines"]) is lines which make read calls those files, hence:

# Example ~/.fvwm/{.fvwm2rc,config} file.
#

# Declare SetEnvs here.
SetEnv RXVT "rxvt +sb -ls -fg white -bg black"

# Add StartFunction here to ensure it gets read before anything else.

DestroyFunc StartFunction
AddToFunc   StartFunction
+ I Module FvwmEvent foo
+ I Exec exec bar

# Now look at everything we have in the separate files.
Read $./fvwm2rc-options
Read $./fvwm2rc-bindings
# Etc ...

Is there a "better" approach?

No, not really. It depends what is meant by better in this context though. There isn't really any real advantage over each of the methods. The single-file approach is good in that there's only ever one file to edit. The multi-file approach is good for those people with tidier minds, and who like to switch different components of their configuration over, perhaps via a symlink (essentially reinventing the wheel a la fvwm-themes).