#fvwm FAQ

IRC is yet another medium to seek help in, and for FVWM, that seems to be more and more popular. There used to be a time when it were just myself, awol, and wombat... This page is intended to help the new-comer into IRC, so that they're not bewildered by all the goings-on that take place.

Excellent! Glad to have you around. Hopefully you'll find what you're looking for, but if not, please let us know on #fvwm on IRC.

Sometimes, the freenode gods, or ops of #fvwm (see #c4) may well decide to limit the type of users who's allowed to join a channel. In the best case, this will just be to restrict those people who do not have registered nicks. To register your nickname on freenode, the following should suffice:

     /msg nickserv register <your-password>

     # Add a valid email address to your primary nickserv entry. If you want
     to keep your email address private, rather than displaying it publicly,
     first mark it as hidden:

     /msg nickserv set hide email on 

     Then set the email address:

     /msg nickserv set email <your-email-address>
     

We're all volunteers that don't get paid to provide support -- so it probably means that some of us are busy working, or getting some tea, or in the best case hacking on FVWM. Be patient, and wait. Someone will eventually answer you. If they don't, ask your question again when it's more busy.

If you have a genuine problem about #fvwm, or any of its members, you can message one of the following people:

• awol
• somiaj
• thomas_adam
• taviso
• saigo
• theBlackDragon

(The list gets longer and longer...)

You can also ask in #freenode, if none of the above people respond to you.

Wombat is awol's bot -- who helps in administering the channel in delegating access rights, and spewing trivia. He's often a great source of amusement.

He has his own homepage too. :)

xteddy is the channel plushy -- who looks after everyone, offering hugs. He also provides drinks and snacks for everyone, and whizzes around the room after having drunk too much espresso. He also keeps track of any screenshots posted. Hug him, and find out. :)

Update: he now has a cute personal website that you can visit to read more about him. :D

• Fvwm Main Site: http://www.fvwm.org
• Fvwm FAQ: http://fvwm.org/documentation/faq
• FvwmButtons Intro: http://forums.gentoo.org/viewtopic.php?t=162177
• Session Management: http://linuxgazette.net/100/adam.html
• FvwmWiki: http://www.fvwmwiki.org
• Tutorials/Guides: http://www.fvwmwiki.org/Tutorials
• Fvwm-Forum: http://fvwm.lair.be
• Screenshots and Configs: http://fvwm.lair.be/viewforum.php?f=39
• Fvwm-Themes: http://fvwm-themes.sf.net
• Lots more links from theBlackDragon: http://lair.be/links_fvwm.php

Alas, even fvwm cannot do everything!

They probably will -- but don't hound them. Be patient, and they, or someone else will help you.

Be clear, and concise as to what you're trying to do. FVWM is vast, and if you're not specific, it's likely the person trying to help you will veer off on a tangent, based on what you're telling them. It's also best to describe any effects you're seeing along with what you want to see happen instead.

Often, it might be the case that you have a lot of information and you don't know the best way to ask your question. That's fine. If you have a question which involves someone possibly having to look at some config -- upload it to the web somewhere. If you have a site yourself, all well and good. If not, the next best solution is to use a paste bin and reference that in your question.

Use of appropriate language is also important, and whilst I sympathise with those whose native language is not English, using lazy English demonstrates laziness on your part -- an assumption that would suggest you aren't prepared to try to do anything suggested. That also means that the person helping you is wasting his/her time (see: #c8.)

If none of this helps you, the canonical reference for all this is best summed up in ESR's smart questions FAQ

See #c4. If you don't like something another person is doing, you can always make use of the /ignore command to not see any messages for them. Being IRC, written communication is always ambiguous. If the offender continues to annoy, the ops can help, at their discretion.

Any public channel on freenode is potentially logged. That is to say, it's either the intent of the channel from the outset that the entire conversation is logged and made publicly available, or, as is the case for #fvwm, individuals log conversations.

Most people generally accept this as the normal conduct. IRC is after all a public place. Would you consider walking down the street, and asking people to whom you pass by not to listen to your conversation? No, of course not -- if it concerned you that much that you didn't want anyone to hear it, you wouldn't be discussing it *openly* in the first place.

The logs in #fvwm are made publicly available over a window of 48 hours, and then they're deleted. Anyone interested can look here: http://awol.no-ip.org/~quark/fvwm.log

I (Thomas Adam) also retain logs of #fvwm going back to 2002, should anyone wish to query them for something.

If this is unacceptable to you, don't say anything. Of course, none of this precludes the possibility that a member of #fvwm might join and then publish the logs.

See this page

Yes, although not natively within FVWM. Because of the JPG licensing issues, support for it is not included in FVWM. That means there's two options. Either you can install imagemagick and use convert as in:

convert file.jpg file.png

Or, use an external program that can set wallpapers, such as feh:

AddToFunc StartFunction I Exec exec feh --bg-scaled file.jpg

Although many people tend to get confused about how to set the wallpaper in general under FVWM. I (Thomas Adam) am not sure why since the process to do is generally well-documented. (Oh, that's probably why -- no one reads anything anymore). Before FVWM 2.5.1 was released (which therefore includes the current FVWM stable releases, 2.4.X) PNG support was not available, the canonical image format being XPM. In FVWM 2.4.X, the in-built program to load a wallpaper is xpmroot. In FVWM 2.5.X, the name of this changed to fvwm-root and hence includes PNG support. So you can use it set the wallpaper. Note that both these programs DO NOT support scaling images. If you want that, either stretch the image yourself, or use feh(1), xli(1), display(1), esetroot(1), etc., as external commands.

The short answer is: probably. In order for the locations of programs you're using to be portable across different resolutions, it is possible to offset them based on the width and height of the current viewport. So for example, let's assume that you want to start 'xteddy' in the same location, find out his geometry via "xwininfo". The first two numbers are the width and height, so you can use:

$[vp.width]

and:

$[vp.height]

to position him. So for instance, assume xteddy had a -geometry of 1021x754, then you can use PipeRead to set the geometry with mathematics, if you wish:

PipeRead 'echo SetEnv offset $(($[vp.width]-22))'

and then set:

xteddy -wm -geometry $[offset]x654

But you can see that this is a lot of work. For more information see the following thread:

That small window that appears in the top-left hand corner of the screen (If you have Emulate Fvwm set), or the centre of the screen if you're using Emulate Mwm is called the GeometryWindow. It's possible to change the colour, font, etc in the usual way. Just declare a Colorset for it, for instance:

Colorset 1 fg white, bg darkgrey

... and then in your FVWM config file, use the command:

DefaultColorset 1

And in the same way, if you want the font to be different, you can use the: DefaultFont command.

Well, I admit, this is one thing that I see people do a lot. I'll first start off by saying that generally, there's nothing wrong with declaring environment variables to hold computed values --- that's primarily why this command exists. Where I have a problem with it, is when people start to abuse it.

Take for instance the Colorset command. The correct definition is for people to do something like this:

Colorset 0 fg black, bg darkgrey

... yet, I have seen some people do this:

    SetEnv hilight_colorset 0
    Colorset $[hilight_colorset] fg black, bg darkgrey

    SetEnv normal_colorset 1
    Colorset $[normal_colorset] fg white, bg blue
    

... now stop and think for a moment. What is it that's wrong with the above? Not much, it's easy to see at a glance what colorset does what --- but it's a waste of space in terms of environment allocation. The variable might only ever be used once -- and that's when the Colorsets were declared. What really needs to happen is for a comment (you know -- those things which are used to be really descriptive and meaningful?) to be used. Here's the rewritten definition:

    # Colorset 0 is for highlighted windows (i.e. they have focus)
    Colorset 0 fg black, bg darkgrey

    # Colorset 1 is for inactive windows (i.e. they don't have focus)
    Colorset 1 fg white, bg blue
    

... so much easier, and we're not having to do any interpolation of variables. I've seen some people try and argue the point that such declarations via the use of SetEnvs are there because they have separate files for different facets of their config. Well, maybe, but duh!, the same argument applies for other configuration commands besides Colorsets. Sorry, but that doesn't wash...

Another example I see of a useless use of SetEnvs (UUOS) is people redeclaring their base-location that FVWM looks in. Here's an example:

SetEnv fvwm_home $[HOME]/.fvwm

Again, FVWM already has this environment variable set as $[FVWM_USERDIR].

See the following page:

IconBox is a style option that tells FVWM where to place any windows that are in the iconic state. By default, unless the user changes it, it defaults to the entire screen. This might be OK in most cases, although some people will want to change it. You can think of IconBox as an invisible window into which icons are placed. The best way of positioning the IconBox is to use a window which resizes in incremental steps. XTerm would be good for this, and assuming that its style is set to 'NoResizeOverride' as in:

Style mySpecialXTerm NoResizeOverride, !Title, !Borders

Exec exec xterm -T mySpecialXTerm

And then position and move it to the relevant place, with the relevant size. You can then obtain the geometry of that window and then set it as the default:

Style * IconBox 900x546+89+5

(for instance). Coupled with that is the position that the icons are placed -- hence that's IconFill.

FvwmIconBox, on the other hand, is a FVWM module which allows for various options to be sent to iconified windows. It's a little bit like an iconic version of FvwmIconMan.

XGL support is the latest buzzword to score with the fanboys of KDE and GNOME, and naturally with all the shiny effects and wobbly windows, people swoon and start to wonder if FVWM will ever support it. Let's face it, the concept is surely like tabbed-browsing, right? One wonders how one ever lived before its arrival? But of course, people _need_ all that superfluous cruft that you'll only ever see nigh on three seconds as you whizz around changing virtual desktops, etc.

The truth of the matter is like everything else -- FVWM might support it at some point in the future -- but at present the emphasis of FVWM's development is to set the milestones that 2.6 will eventually uphold before the upcoming FVWM3 release. You have to understand that XGL, whilst it is primarily based in X11, still requires some level of interactivity from the window manager.

So sit back and wait. Let the hype go away, the enormous (what is likely to be) bug reports diminish, and then we will see what FVWM's stance on all of this is. If that's still too slow, you can always write patches to include XGL support...

Past experience tells me this won't happen.

There's a certain property within the WM_HINTS XAtom that, when set, causes the specific window to get top priority via the window manager. It seems Gaim and XChat do this to denote the fact that someone is explicitly referencing your IRC name, for instance. For some people this can be very annoying, and thankfully there's a few things that can be done about it. Whenever a Urgency hint is set on a client, FVWM notices this and immediately executes a builtin function: UrgencyFunc as described below.

    DestroyFunc UrgencyFunc
    AddToFunc UrgencyFunc
    + I Iconify off
    + I FlipFocus
    + I Raise
    + I WarpToWindow 5p 5p
    

Hence it is the "FlipFocus" line that causes the viewport to change, especially if the said client is on another page. Most people want to turn this off. The simplest way of doing that is to add the following to your config file:

DestroyFunc UrgencyFunc

And that way, any UrgencyHints are ignored by FVWM. You can of course (just like any other function) redefine this to do whatever you like -- it's up to you. Note also that there is another function that gets called after the Urgency flag has been cleared, and that is UrgencyDoneFunc -- although by default this has No Operation (Nop) defined for it.

The WindowList defaults to showing all windows across desks and pages. The WindowList command, like some others, accepts various conditions, hence you'll want to use:

WindowList (CurrentPage) ....

This is mostly an expansion of what has already been covered in the Fvwm Cookbook

Starting applications up in so-called "fullscreen" mode, requires several things. Indeed, the size of a window is something the client sets itself before it is mapped. Changing this (to suit a fullscreen mode) isn't something FVWM should interfere with. However, once can coerce an application into changing its geometry after it has appeared.

Typically when someone asks this question, what they're really asking is: "I want to start this application up in fullscreen mode without any window titles or borders". Let's deal with that first. Setting up a style line is generally all that's required:

Style some_window !Title, !Borders

Then the actual operation of making sure the window is maximised can be done in one of two ways. The somewhat more restrictive approach is to use a function, which will launch the desired application, and then maximise it:

    DestroyFunc StartAppMaximized
    AddToFunc	  StartAppMaximized
    + I Exec exec $0
    + I Wait $0
    + I Next ($0, !Maximized) Maximize
    

StartAppMaximized my_application

However, there are several drawbacks in using this approach. First of all the said application can only be launched via the function (and hence FVWM) -- so it will work fine if launched via a menu or an FvwmButtons, but will fail hideously if launched from a standard console (the use of FvwmCommand here is superfluous, and completely unnecessary). What is perhaps more portable is to have some way of identifying the window as it is created ("mapped" to use XLib parlance) so that launching the program is not dependant on FVWM. You can do this using FvwmEvent.

    DestroyModuleConfig FE-startMaximized: *
    *FE-startMaximized: Cmd Function
    *FE-startMaximized: add_window StartAppMaximized

    Module FvwmEvent FE-startMaximized
    

The above just declares and starts an FvwmEvent instance which will listen on the add_window event -- each time a window is mapped to the screen, it will call the StartAppMaximized function. Hence we can declare in this function the windows we want to maximize, as in:

    DestroyFunc StartAppMaximized
    AddToFunc   StartAppMaximized
    + I ThisWindow (some_name, !Maximized) Maximize
    

Hence the function checks to see if the window is called "some_name" (you'll want to change this to something appropriate) and if it isn't maximised, to maximize it. One could of course be pedantic enough to say that the conditional test of !Maximized isn't enough since not all XClients allow for themselves to be maximized (and can be told explicitly not to be allowed via the !Maximizable Style condition in FVWM 2.5.X) however this command will just fail.

The following is also recommended reading:

The rubber-band effect (what looks like a grid made up of nine squares, in a 3x3 layout) is a way of visually seeing a window in a move or resize operation, but not to see its contents. Most applications don't like to have their contents visible during this operation. If you want to turn it off, then you can uuse the following:

    # This is for a Move operation
    OpaqueMoveSize -1

    # And this is for Resize.
    Style * ResizeOpaque
    

The slightly longer reason as to why this is also useful comes about from the way the rubber-band is implemented. It has an Xor value (which can be changed) which affects various aspects of it -- such as colour, etc. The downside to this though is that when it is in use, the XServer is grabbed. This generally has the effect of "halting" various applications, especially things like media players. Hence the above configuration is also useful in these situations.

You're an idiot. You probably didn't compile in XFT support. FVWM needs this to render XFT fonts. If the command:

fvwm --version | sed -n 2p

... doesn't have "XFT" listed in its options, then install the XFT header files (libxft-dev, if you're on Debian) and recompile FVWM.

You can learn a little bit about X11, I suppose. Seriously, when most people ask this question what they're really asking is something like: How do I add FVWM or Fvwm-themes as an option to KDM or GDM but then again being specific about their question is something no one delights in doing, so I tend to dance around the fire a little before I get to the heart of the problem in its proper context. Sigh.

However, here's what happens in the general sense. {K,G,W,X}DM aside for the moment, back in the day when X was started via xinit(1), that would read the file $HOME/.xinitrc -- of course, startx(1) also reads this file. Why? Because, yes, that's right, it's simply a wrapper script around xinit(1). Now, here's the good part: it's a shell script so treat it as such. That means it gets its own shebang line and octal permissions of 700. At the most basic level it looks like this:

     #!/bin/sh

     exec fvwm
     

Yes, it's that simple. That simply says to exec (i.e. replace the current shell the script is running in) with the FVWM process. You can exapnd it of course (as shown in #df1) to include logging information from FVWM:

exec fvwm >>~/.xsession-errors 2>&1

The ~/.xsession file however is read by any decent display manager, as well as startx(1) ONLY if ~/.xinitrc is not present. Note that ~/.xinitrc takes precedence over anything else as far as startx(1) is concerned. XDM reads ~/.xsession as its per-user configuration file. In fact, *any* display manager should be reading that file, although KDM and GDM are fundamentally broken in this respect. No surprise there -- they delight in attempting to do things Their Way (tm) eschewing any form of established principles. Yes, they have some form of "failsafe" option, but that's NOT the point at all. One has to hence dick about with changing various .desktop files in /etc/X11/gdm, which is utter shit. Personally speaking I would force {G,K}DM to run in "failsafe" mode and trust it will read ~/.xsession, hence all your changes to your X environment should live here.

As for fvwm-themes, just substitute fvwm-themes for fvwm in the examples above.

Yes, you can. On most systems, FVWM will log to the file ~/.xsession-errors, as a matter of using startx(1) or xdm(1). If you're not using a Display Manager that reads ~/.xsession, then you can add/amend the line:

exec fvwm > ~/.xsession-errors 2>&1

to that file, and restart X11.

If you suspect FVWM is producing errors in the config, or you have a situation that's specific to a module (such as an error in a FvwmButttons configuration), then the best thing to do is to produce a minimal configuration that exhibits the problem, and put it into a file. Then, in FvwmConsole, one can type:

Restart fvwm -f $[HOME]/myexampleconfig

Or some such. Tailing ~/.xsession-errors in this case, is also advisable as the file loads.

In some instances, there might be some issues in working out why a specific window is not being placed in the correct position. Invariably this might be because the client in question is not ICCCM2 aware -- and FVWM tries to adhere to this as much as possible. EWMH-type applications are typical of this, they tend not to accept -geometry options. In situations such as this, getting FVWM to tell you where and why it decided to place that window in a specific place can be useful, hence:

BugOpts ExplainWindowPlacement On

Then the results of which can then be seen in ~/.xsession-errors

Heh. To answer this requires that you understand a little bit about what happens during the execution of a complex function. Without going into too much detail, whenever a complex function is executed, the pointer is grabbed. This is largely due to the fact that if a user (or indeed, a broken application -- often is the case) tries to do something during the function's lifetime, clicking the mouse to cause some other event would screw things entirely.

Typically, if something goes wrong (and in version prior to FVWM 2.5.12, including FVWM stable, 2.4.X) an XBELL would get triggered. With recent versions of FVWM post 2.5.12, this is no longer the case, favoured instead with there being a message printed to STDERR, which gets logged typically to ~/.xsession-errors. Not that the error can tell you what went wrong... In either case, it's most likely not the function in question, but a buggy application trying to grab the pointer and failing.

The first thing to do is not to panic. FVWM crashes for usually genuine reasons, so it's probably a rather odd bug that's present. Often though, FVWM crashes because it cannot handle buggy applications, and rightly so -- FVWM shouldn't have to circumvent the poor programming of others -- it seems far too many people think this to be the case.

What has to happen first of all is to ensure this bug is reproducible. If it is, then great -- the next step is to turn on corefile creation. Distributions of years ago used to leave this enabled by default, and then define cron jobs that would typically run daily to remove them. Since 99% of people don't care for these files, most distributions now tend to disable them.

So -- the first thing to do is to tell the distribution to enable core files. This is going to have to be done before FVWM starts (see #cf14) by using the following command:

ulimit -c unlimited

Note that ulimit is a bash builtin, although since most shells default to bash, this isn't too much of an issue for some. What this command does is to enable core file creation of an arbitrary size (in this case). When FVWM crashes, the core file will get dumped to the CWD of the application, which is probably going to be $HOME.

Having got the core file (check using: ls -l ~/core), one can now analyse it. One will hence need to install gdb to do this. Since X11 is needed to run FVWM (alongside the corefile) one can issue the command:

xinit

... having first quit X11. That should start a single xterm into which one can type:

gdb fvwm ~/core

This will (hopefully) leave a prompt which looks like this:

(gdb)

Into which, one would type:

where

To obtain the backtrace -- it's this information that can then be used in tracking down the problem. A description of the problem, along with a method of reproducing it, and the backtrace from the above should then be sent to the fvwm-workers mailing list.

FVWM is an ICCCM2 compliant window manager that's over ten years old. It was written by Rob Nation because he was tired of twm taking up so much memory. It's also an incredibly powerful, extensible and customisable window manager that can emulate almost all other window managers. It also has support for KDE and GNOME apps, as well as session management, xinerama, and lots more. Lots, lots, more.

Although the answer to this is much like #c7, there is efforts underway to improve this aspect of FVWM. Whilst it isn't to everyone's preference; the canonical reference for FVWM is its man page. As of January 2006, I am heading up efforts to seriously revamp the FvwmWiki -- a task I am thankful to say has attracted some attention. So it is worth looking there.

Also, some of us have been attempting to compile a set of things to read on the forums, you can find it here:

Code examples are usually somewhat trickier to come by. Indeed, the best resource I can think of is the Fvwm Forums. If you're specific enough in using appropriate search items, you'll likely find it there. Then of course, there is also the Fvwm Cookbook, which details specific examples of how to apply a given task -- the overall aim of which is to develop transferable skills when trying to write functionality in FVWM. In most cases, FVWM configuration isn't hard -- since all of it comes from the amalgamation of certain key skills.

The last resort is to try IRC. :)

Created by Thomas Adam -- last modified 2006-07-17, 13:59 BST. Version 3.4