Upgrading From FVWM2 to FVWM3 (and key features in FVWM3)

[ThomasAdam]

Introduction

This document outlines some of the key things to consider when looking at the differences between fvwm2 and fvwm3. Note that this is not an exhaustive list of changes -- for the specific details, always refer to the release notes.

None of the changes below are in any particular order.

Colorsets

fvwm3 now makes an attempt to standardise how colours are used. For absolute yonks, Colorsets have always been the preferred way of defining where and how to use colours. Prior to this, there were various commands which allowed for colours to be defined.

The following table shows which commands have been deprecated, and what they could be replaced with in fvwm3:

Deprecated Command(s)	Replacement
DefaultColors	Uses Colorset 0
DefaultColorset	Uses Colorset 0
Color	User-defined Colorset
ForeColor	User-defined Colorset
BackColor	User-defined Colorset
HilightFore	User-defined Colorset
HilightBack	User-defined Colorset

The same is true of the MenuStyle options as well:

Deprecated MenuStyle Command	Replacement
Foreground	Uses Colorset 0
Background	Uses Colorset
Greyed	User-defined Colorset
MenuFace	User-defined Colorset

RandR Support rather than Xinerama

RandR replaces the older Xinerama implementation. This not only changes how monitors are detected, but also how they're referred to in fvwm3.

There are two main ways to refer to monitors in fvwm3, either by the explicit name RandR assigns them (see xrandr q), or by their assigned number, which fvwm3 gives to monitors.

fvwm3 will assign connected monitors a number in topological order, for example, if one's monitor layout as configured by RandR were to look like the following:

+---++---++---+
| 0 || 1 || 2 |
+---++---++---+
     +---+
     | 2 |
     +---+

Then fvwm3 would assign a number to each monitor as shown. The corresponding monitor names for this would be:

[~]{7744} % xrandr --listactivemonitors          
Monitors: 4
 0: +*DP-1 1920/527x1080/296+1920+0  DP-1
 1: +DP-2 1920/344x1080/194+1920+1080  DP-2
 2: +DVI-I-2-2 1920/527x1080/296+0+0  DVI-I-2-2
 3: +DVI-I-1-1 1920/527x1080/296+3840+0  DVI-I-1-1

Hence, the following geometry string, would place an xterm on monitor 1

Exec exec xterm 80x24+100+100@1

Or to use the explicit name:

Exec exec xterm -g 80x24+100+100@DP-1

This pattern of referring to fully-qualified monitor names, is also true for commands which accept a screen argument. Such as:

• MoveToScreen
• MoveToDesk
• MoveToPage
• EWMHBaseStruts
• EdgeCommand

Note that there are also expansion variables in the form of $[monitor.XXXX] -- see man fvwm3all for more information. Some deprecated variables include:

Deprecated Variable	Replacement
$[screen.count]	$[monitor.count]
$[pointer.screen]	$[monitor.current]

Note that to refer to a monitor's name via it's number, you can refer to it in expansion string as:

$[monitor.2.name]

Which would expand to DVI-I-1-1 in the example layout above.

Geometry Strings, and referencing monitors

Some modules, such as FvwmPager and FvwmIconMan would use the Primary screen when placing windows, if no monitor was given.

Now though, if a geometry string is used without a screen identifier, such as:

100x100+0+0

Then the global screen is used -- that is, the combined geometries of all connected monitors -- or the root window size.

To enforce a particular geometry to a given monitor, you can use:

100x100+0+0@MONITORNAME

This @MONITORNAME extension on the XGeometry string is non-standard, and is something only FVWM will understand.

Valid names for @MONITORNAME are an explicit monitor name as returned by xrandr(1), as well as the following special references:

• @g -- the global monitor (root window geometry)
• @c -- the current monitor (the monitor which contains the mouse pointer)
• @p -- the primary monitor, as set by xrandr -- or in such cases where there is no primary monitor set, the first monitor FVWM detects.
• @n -- where n is a monitor's assigned number. (See above)

DesktopConfiguration

Because fvwm3 now supports RandR, it was easier at that point to also change fvwm3 to allow for per-monitor desktops and pages. By this, each monitor is able to have its own copy of desks/pages independent from one another. To enable this, use:

DesktopConfigutation per-monitor

The default behaviour is:

DesktopConfiguration global

.... which treats desks and pages across multiple monitors the same as in fvwm2.

There is also a shared mode which works like XMonad:

DesktopConfiguration shared

NOTE: The DesktopConfigutation command only works if more than one monitor is in use.

EdgeResistance and Page Scrolling

For now, to ensure moving between pages continues to work, add the following to your configuration file:

EdgeResistance 2

FvwmConsole vs FvwmPrompt

To try and alleviate some of the concerns over FvwmConsole, FvwmPrompt was written to replace it. It's not perfect, but for most should largely be a drop-in replacement for FvwmConsole.