I don't use a standard desktop environment like Gnome, KDE, XFCE, or Cinnamon on my home and work desktops (I do use Cinnamon on my work laptop because it was the easy way). Instead I use a custom X11 environment with FVWM as the window manager. Specifically, I used FVWM version 2 ('fvwm2'), until recently when I had to switch to fvwm3, (aka 'fvwm 3') because that was the easiest way to work around what was effectively an API change in libX11 1.8 (see this Fedora issue, also (via)). Fvwm 2 isn't being actively updated any more so it was unlikely to get a 'fix' for the libX11 API change, while Fvwm3 had been fixed as part of general updates to its code.

(The libX11 people would argue that they were merely enforcing an already documented API restriction, but Hyrum's Law applies.)

As I write this, the latest tagged ('released', sort of) version of fvwm3 is 1.0.6a. I'm using a custom build of the current git tip, because it contains some bug fixes that are important to me (#810, #811, and #813). A future 1.0.7 fvwm3 release will include those (and probably also a real fix for #693/#818). The current state of things is that fvwm3 works stably for me and is just the same as fvwm2, which is basically why I didn't try upgrading to fvwm3 before now. However, it took some changes to my old fvwm2 configuration to get there.

Much of what I had to change was updating to modern fvwm2 practice instead of multiple decades old things. What I needed was:

• while fvwm2 supports directly setting colors and some color effects in various places as well as colorsets, fvwm3 only supports colorsets. For historical reasons my fvwm2 configuration wasn't using colorsets, so I had to update it to do so.

  Colorsets are mostly okay but they have some slightly rough edges. One of them is that one use of colorsets (the GreyedColorset in MenuStyle, used for greyed out menu entries) uses only the colorset's foreground color. So I wound up with a colorset that existed to specify exactly one color.

• in fvwm2, you could specify that you wanted to move a window relative to the (Xinerama) screen it was on with a short form of 'Move screen w'. In fvwm3 this old syntax has been dropped and I needed to switch to 'Move screen $[w.screen]'.

• the fvwm3 documentation currently says that FvwmPrompt is the intended modern replacement for FvwmConsole. Unfortunately FvwmPrompt currently has quoting issues that can make it unsuitable for this, per issue #662. In the current fvwm3 'configure', you must build without Go support in order to still build FvwmConsole (I patched my setup to build both FvwmConsole and FvwmPrompt).

  To use FvwmPrompt, you'll need to include starting the 'FvwmMFL' module in your StartFunction. If you already start 'FvwmCommandS', that's now the same thing (in fvwm3 it transparently starts FvwmMFL), but you might as well update to use the real module name in fvwm3.

• fvwm2's Xinerama support allowed you to specify what Xinerama screen you wanted (fvwm) geometries to be relative to by using '@0', '@1', and so on. In fvwm3, you must use the (X)RandR screen names instead, such as '@DisplayPort-0'. Fvwm3 has a notation for the primary RandR screen ('@p') independent of how it's connected today, but not for additional RandR screens, which can only be named by their current physical connectors.

  (I use this at work to position one FvwmPager window on each display, and to place FvwmIconMan.)

If you're a fvwm(2) user who's tempted to try out this transition, you can make your life easier by adding entries to both your fvwm2 and fvwm3 configurations to restart the other window manager, as well as the current one. So these days I have two 'Restart ..' entries in one of my menus:

+ "Restart Fvwm3"	Restart
+ "Restart Fvwm2"	Restart fvwm2

This makes it much easier to switch back and forth so you can see how something worked in fvwm2, or take a break from trying to make some bit of your fvwm3 configuration work. I found that it took me a number of go-arounds with fvwm3 restarts before I had my configuration settled down.

If you don't use per-screen placement in a multi-screen environment, I believe it's technically possible to use the same configuration file for fvwm2 and fvwm3, since fvwm2 supports colorsets and the '$[w.screen]' syntax. I opted to have a separate fvwm3 configuration file so that I could edit it around without worrying about blowing up my working fvwm2 environment.

PS: I'm not sure if fvwm3 has had an official real release yet, or if it's still considered somewhat in development and not necessarily quite ready for a (very small) flood of fvwm2 users. The libX11 1.8 change probably isn't going to leave people with much of a choice, though.