Fvwm Begnners Guide background problem

I am for the most part emulating the fvwm2rc configuration outlined in this Guide, and am proceeding slowly but with a measure of success. But I seem to be incapable of getting a background (wallpaper) to work. I only, and always, get a black screen.

I have formatted my background selection (“wall28”) as .jpg, .png, and .xpm. It resides in several of my various fvwm directories, such as “home/jim/.fvwm/wallpaper”. But I can’t seem to be able to modify the Guide’s configuration to get this background to work in this Guide-inspired .fvwm2rc. (By the way, I’ve got it to work fine in my Fvwm-Themes personal theme.)

Can anyone provide me with the specific command (function?) code to use?

Many thanks. Jim

ImagePath $[FVWM_USERDIR]:$[FVWM_USERDIR]/wallpaper:+

AddToFunc StartFunction I Test (Init) Exec exec foo my_image.png

Where “foo” is any of the many background programs available such as ‘feh’, ‘fvwm-root’, ‘esetroot’, etc. Refer to other posts on this.

– Thomas Adam

Thomas: Sorry, this seems to be beyond me. The “Guide” seems to designate “fvwm-root” as its background program in other parts of the “Guide” code. But of course that doesn’t necessarily mean that that’s the one I have in my system. What command do I execute to determine what background program I in fact do have? Is it possible I don’t have any? But then my Fvwm-Themes background selection process works fine – but then I suspect I’m talking apples-and-oranges here.

Well, fvwm-root is shipped with FVWM, but it’s limitation is that it doesn’t tile or stretch the pixmap it’s told to load. This is why many people choose to use feh or esetroot which are external applications not shipped with FVWM.

Another reason to use feh or esetroot for instance is that many people seem incapable of converting JPG images (which FVWM cannot internally load) to PNG files. So if you want to load a JPG you’ll have to use one of these.

It really isn’t a difficult concept to grasp.

– Thomas Adam

Thomas: I long ago downloaded and install ImageMagick (even before I knew what it really accomplished). Then when you suggested awhile back that I convert my .xpm files to .jpg using Image Magick, I was readily able to so do. And I’ve now converted my wall28 file from its initial .jpg form to both .xpm and .png (and I have all these versions in my same .fvwm/wallpaper directory. So at least that’s not my problem here. I will however download feh or esetroot and have another go.

I am possibly confused by your recent '$[FVWM_USERDIR] designation. In my case, I’m operating out of my “home” directory of /home/jim, and doing my fvwm work out of my /home/jim/.fvwm directory. So, should my $[FVWM_USERDIR] be designated as $HOME/.fvwm in my code?

Again, thanks. Jim

I never suggested you conver them to JPGs. I might have said something arbitrary such as PNG, but not JPG – that would be shooting yourself in the foot slightly where FVWM is concerned.

You can try them out by all means, but they won’t be using the ImagePath directive, given that they’re external applications. Launced from within FVWm of course, you can do something like this:

Exec exec fvwm-w00t $[FVWM_USERDIR]/wallpaper/name_of_wallpaper_to_load.png

That was me being somewhat anticipatory to your further use of images for things like menus and stuff should you ever get that far. FVWM maintains a collection of directories that it can search to load various images. This is useful when you’re trying to add pixmaps to titlebars, set icons and miniIcons etc., where you don’t want to have to specify the full path to it. It operates in exactly the same waythat ModulePath does (you know all about that now), such that if you were to have this set:

ImagePath $[FVWM_USERDIR]/icons:+

That then tells FVWM that if it comes across an image file name that doesn’t have the full path given to it, that it can start traversing the directories listed in the ImagePath the user has specified. So, say for instance you decided you want to give all xterms an icon called ‘xterm.xpm’:

Style Xterm Icon wterm.xpm

FVWM comes across that filename, and starts looking in $[FVWM_USERDIR]/icons (more about that later). If it finds it in there, then it will load it and stop looking. Otherwise it will carry on looking in the other directories listed. Of course, you might well tell me that there aren’t any. Except of course there are – they’re just no explicit. The “+” in this case means append the previous definition. And in this instance, the previous definition is the default iImagePath which FVWM defines as being the following:


So really what that FVWM sees as far as that ImagePath line is concerned is:

ImagePath $[FVWM_USERDIR]/icons:/usr/include/X11/bitmaps:/usr/include/X11/pixmaps

If FVWM doesn’t find our wxterm.xpm file in any of those directories, then it won’t assign the icon we asked it to. And in much the same way with PATH at the shell, FVWM stops traversing the directories on the first match made. So if, for instance you had two files called wxterm.xpm in say “/usr/include/X11/bitmaps”, and “/usr/include/X11/pixmaps”, FVWM would load the file found in “/usr/include/X11/bitmaps”.

Next, then. The mysterious FVWM_USERDIR variable. It’s one that’s been misused/abused/ignored slightly by up and coming FVWM-enthusiasts, alas (c.f: viewtopic.php?t=1505). This is the location of the directory which FVWM will look for your configuration file. It defaults to $[HOME]/.fvwm – which should indeed be where your files are stored in terms of FVWM configuration. But it’s not added to the default ImagePath location. It probably should be – I might go and rally the fvwm-workers mailing list to see what they see about this. But adding $[FVWM_USERDIR] to your ImagePath along with the path to any subdirectories therein allows for much greater control when you come to expand your image additions for things like menus and icons.

– Thomas Adam

Wow! Great information. Many thanks. Much food for thought – which I’ll shortly feast upon – and maybe even ultimately resolve some of the snags in my attempted configuration. Regards, Jim

Thomas: I finally got my background (“wall28.png”) to appear through trying many of the options you presented or inspired me to. I actually loaded most of them at once(!), then when the background finally appeared, I narrowed down which of the commands was the operative one through commenting-out the various commands. The sole(?) one that ultimately worked was:

#Startup Functions


  • I Exec exec fvwm-root -r $HOME/.fvwm/wallpaper/wall28.png

That gave me a very satisfactory tiled background (the same as in my Fvwm-Themes version). If I substituted “feh” (which I’d installed) for the “fvwm-root” in the command, I got a 48x48(?) thumbnail on the screen, with the background otherwise black.

That’s enough experimentation for today. Again, many thanks. Jim

As per the link in my previous reply, you shouldn’t be using InitFunction in lieu of StartFunction.

Again, as explained in my previous post, you have to tell feh to scale the image, as per --bg-scale and --bg-tile options to feh,

– Thomas Adam

I hadn’t yet a chance to study your link, but will do so shortly. And I will work with feh to eliminate the tiling. (And again, you’e up much too late!) Regards, Jim

Thomas: I’ve read the link you directed me to regarding SetEnv vis a vis ImagePath, StartupFunction vis a vis Initfunction, etc., and found it very illuminating. I employed all those because they were in the Guide’s fvwm2rc. Of course, I recognize that because the Guide’s configuartion was based, I believe, on fvwm version 2.4 rather than 2.5, the use of them possiby made more sense.

I’ve put the few items I had in the InitFunction into the StartupFunction. No problem.

But let me make certain I understand what you’re recommending re SetEnv, i.e., that we don’t really need it as long as we structure the ImagePath correctly. But what about such items as the following, which I have designated as an Environment variable, again taken from the Guide fvwm2rc:

“SetEnv fvwm_webbrowser /usr/bin/firefox.”

I’m assuming that that stays where and as it is.

Thanks again. Jim


– Thomas Adam