#fvwm FAQ

Historical note: This was originally maintained by one person for about three years, however that person has since given up ownership of it in the hopes others can add to it.

I’m a Newbie

Oh really? That’s nice. What, you somehow expected that you’d be treated differently, and that we’d be any more (or less) kind to you? Calling yourself a newbie is a self-imposed label – a categorisation into which you are placing yourself. Often, these so-called newbies seem to think that in calling themselves that, they’re entitled to special privileges in some way – such as an increase of attention, or a more tailored answer handed to them on a spoon so that they don’t have to do any work themselves.

Wrong.

Being a newbie means nothing. It’s not a means of getting a faster or more exact answer. This supposed newbie is still able to read. They’re still able to actively look up information and to read various bits of information pointed out to them. Where they tend to differ is that they’re lazy – they don’t ‘‘want’’ to do any of the work, so they let others’ do it for them. Added to which, there’s a certain inferiorty complex associated with this self-imposed categorisation – in calling oneself a ‘'’newbie’’’, they’re effectively saying: “I need help, but don’t really understand, because I’ve already decided such a task is too complex.” That is of course wholly defeatist. ‘‘Wake up, damnit.’’ You’re just as capable, if you only did something a little more proactive than to sit back, and passively deny the fact that you’re incapable.

I (Thomas Adam) have no compunction for newbies. It’s obvious when someone asking a question is new to FVWM (or any subject matter that I provide support with). The difference between this newcomer and a supposed newbie is that the newcomer is the polar opposite of the stereotypical trends I have observed with newbies. They’re typically much more receptive of the answers given to their questions, and will actively sought to digest and ask intelligent questions based on the answer.

Why can’t I join #fvwm?

Sometimes, the IRC gods, or ops of #fvwm (see [:HashFvwmIrcFaq#4:FAQ 4] 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 IRC, 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>

Why is no one answering me?

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.

Who do I ask for help about #fvwm?

The current channel maintainer is thomas_adam – if you have any question specifically about the channel in general, ask him.

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

Historically when this channel was on Freenode (no longer true as of May 2021), the following users had ops, but no longer. This is left here as a sidenote in history

(The list gets longer and longer…)

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

Who is Wombat?

Wombat was awol’s bot before his unfortunate death; he helps in administering the channel in delegating access rights, and spewing trivia. He’s often a great source of amusement.

I’m new to FVWM – any cool links?

FVWM can’t feed the cat for me, what gives?

OK, so FVWM cannot do everything. You came here expecting it did? And now you want the moon on a stick as well? Sorry, but that’s not how things work. I’m sure it can feed the cat for you, but you probably haven’t explained things correctly. FVWM is a very subjective and almost personal window manager, that it’s often the minutiae that people want to configure. That’s fine, and we’re prepared to help you with that, but you have to show some signs that you’re at least trying to help yourself as well. You have to show you are learning, otherwise how else can we help you? It’s a bi-directional conversation. Stick to that, and everything will be just fine.

Of course, if you’re bitching for no discernible reason, you could always STFU and actually do something about the very thing you’re whinging about – but of course, that’s not likely going to happen. It might even be the case you’re suffering from [:HashFvwmIrcFaq#1:newbie syndrome] in which case hard luck to you. You know where the door is. Should someone point this out to you in the channel, all well and good, and heed upon it.

PersonX was really helpful last time. I wonder if they’ll be like it again today, too…

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

What’s the best way to ask my question?

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 pastebin and reference that in your question.

Use of appropriate language is also important, and whilst I sympathise with those who’s 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.

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

PersonX is really annoying. What do I do?

See Q4. 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.

Are the conversations that take place in #fvwm logged? If so, are they available for viewing?

Any public channel on IRC 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.

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.

Where’s the GUI config tool for FVWM?

See this page: https://xteddy.org/fvwm/user_enumerate.html

Can I use JPGs as Wallpaper? – or – How do I set the wallpaper in FVWM?

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.

I’m {using,creating,porting,whatever} my FVWM config file but I use ${hugscreenX}x${hugescreenY} resolution, whereas some only use 1024x768. Can I scale my geometry settings correctly?

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.

How do I change the colour of the GeometryWindow that appears when I move or resize a window?

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.

This Thomas Adam guy - what does he mean when he says: “it’s bad to pollute the environment?”

There’s nothing wrong with declaring environment variables to hold computed values — that’s primarily why this command exists. Where it starts to become a problem 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 hilighted 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. Lots of 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 where there’s a lot of 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].

Argh, my style lines aren’t being applied, or they’re being applied randomly even though the window has loaded. What’s going on?

See the following page: https://linuxgazette.net/127/adam.html

What’s the difference between IconBox and FvwmIconBox? -or- How do I tell FVWM where to place my icons?

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

Then you can launch something like:

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.

Will FVWM ever support XGL?

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…

Why do certain applications such as GAIM and XChat steal focus/switch pages/etc., at certain times?

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.

How can I tell WindowList to only show windows on the current page?

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

WindowList (CurrentPage) ....

How can I make my application startup in a fullscreen” (maximized) state? I don’t see a style option for fullscreen” (maximized) state? I don’t see a style option for it.

This is mostly an expansion of what has already been covered in the [[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

(Or if you’re using FVWM 2.4.X: Style some_window NoTitle, NoBorder, BorderWidth 0, HandleWidth 0)

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

Hence this can the be used thusly:

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: https://linuxgazette.net/127/adam1.html

How do I turn off the rubber-band effect when I try to resize/move windows?

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.

I compiled FVWM from source, and now none of my XFT fonts are working. They work fine under other window managers.

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.

I installed FVWM/fvwm-themes and I can’t work out how to run them. What do I do?

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 [:FvwmIrcFaq#X: as shown here] 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-start for fvwm in the examples above.

FVWM doesn’t do what I have asked it. Can I debug it somehow?

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

Sometimes I get really odd results when executing a complex function. Why?

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.

FVWM crashes. What do I do now?

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.

Before going any further, it’s important to get a debug build – that is, to compile FVWM with “-g -ggdb”. These can be set in CFLAGS.

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 shell 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:

bt full

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.

Are there any good resources for documentation or FVWM “code” examples?

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 manpage. As of January 2006, ThomasAdam is heading up efforts to seriously revamp the FvwmWiki – a task that has attracted some attention. So it is worth looking there.

Code examples are usually somewhat trickier to come by. Indeed, the best resource 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 [[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. :)