Fvwm3 on dev@iostream.pl

Escape from the Tropics

Mon, 05 Oct 2026 15:05:00 +0200

KDE Plasma is a remarkably pleasant environment for work — and for pretty much everything else — so there is very little to complain about.

However, since I have already taken the first steps toward moving completely to FVWM3, a little consistency seems appropriate.

It is time to start replacing some of the applications from the KDE ecosystem as well.

Not all at once.

No need to panic.

First, we need a survival kit.

Minimal Version

The absolute minimum I would find difficult to live without is:

another terminal → Alacritty, because why not,
another file manager → PCManFM-Qt — I used its GTK ancestor about twenty years ago, so now the Qt version gets a chance,
Qt appearance configuration → qt6ct — without it, surprises await,
somewhat more deliberate wallpaper handling → feh,
a launcher slightly more sophisticated than dmenu → rofi,
display configuration management → autorandr and arandr.

There is one additional detail with qt6ct: Qt applications need to know that they are supposed to use it.

An FVWM session will therefore eventually need something along the lines of:

export QT_QPA_PLATFORMTHEME=qt6ct

Simply installing qt6ct does not magically make it take control of every Qt application.

Unfortunately.

The magic comes later.

Standard Version

The standard version contains everything from the minimal one, plus:

Bluetooth device management → blueman,
display brightness control → brightnessctl,
notifications → dunst,
a PolicyKit authentication agent → lxqt-policykit,
screenshots → flameshot,
NetworkManager connection management → network-manager-applet,
an audio mixer → pavucontrol,
an X11 compositor → picom,
media-player control → playerctl,
automatic removable-media mounting through UDisks → udiskie,
a volume-control applet → volumeicon,
a second terminal, for variety → qterminal,
a system tray → stalonetray.

At this point, an innocent little window manager starts looking suspiciously like a desktop environment.

But that is fine.

We still know exactly what it consists of.

Full Version

Naturally, the full version requires the standard version and all of its dependencies, and adds:

yet another terminal, just to prevent boredom → kitty,
another file manager → Thunar.

Three terminals may sound excessive.

They are not.

RPM Packages

Since Fedora is now my main operating system, there is an obvious next step:

package all of this as RPMs.

Right?

Right.

The packages do not even need to contain any programs or configuration files of their own.

What we need are metapackages — almost empty RPM packages whose main purpose is to depend on other packages.

Instead of remembering fifteen package names, I should eventually be able to type:

sudo dnf install kde-refugee-pack-standard

and be done with it.

Tools

First, install the basic RPM-building tools:

sudo dnf install rpm-build rpmdevtools rpmlint

Create the standard build tree:

rpmdev-setuptree

and generate a fresh spec template:

rpmdev-newspec my-package.spec

A typical spec template contains fields such as:

Name,
Version,
Release,
Summary,
License,
URL,
Source,
BuildRequires,
Requires.

It also contains sections such as:

%description,
%prep,
%build,
%install,
%files,
%changelog.

For a package consisting entirely of dependencies, most of these are unnecessary.

There are no sources.

There is nothing to compile.

There is not even anything to install into the filesystem.

Minimal

The kde-refugee-pack-minimal.spec file can therefore look like this:

Name: kde-refugee-pack-minimal
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, minimal version

License: MIT
BuildArch: noarch

Requires: alacritty
Requires: qt6ct
Requires: pcmanfm-qt
Requires: feh
Requires: rofi
Requires: autorandr
Requires: arandr

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(minimal version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

Important: keep the empty %files section.

The package does not contain any files, but we still want rpmbuild to produce a binary RPM.

That is its entire purpose:

to exist and require other packages.

Standard

The next level depends on the first one:

Name: kde-refugee-pack-standard
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, standard version

License: MIT
BuildArch: noarch

Requires: kde-refugee-pack-minimal = %{version}
Requires: blueman
Requires: brightnessctl
Requires: dunst
Requires: flameshot
Requires: lxqt-policykit
Requires: network-manager-applet
Requires: pavucontrol
Requires: picom
Requires: playerctl
Requires: udiskie
Requires: volumeicon
Requires: qterminal
Requires: stalonetray

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(standard version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

The important line is:

Requires: kde-refugee-pack-minimal = %{version}

which means:

I require kde-refugee-pack-minimal in the same version as this package.

Of course, this could be written explicitly:

Requires: kde-refugee-pack-minimal = 0.0.1

but %{version} saves us from having to remember to change it in the next release.

Laziness.

Once again, the driving force behind computer science.

Full

The final level:

Name: kde-refugee-pack-full
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, full version

License: MIT
BuildArch: noarch

Requires: kde-refugee-pack-standard = %{version}
Requires: kitty
Requires: Thunar

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(full version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

This gives us a dependency chain:

full
 └── standard
 └── minimal

with each level adding its own collection of tools.

Building the Packages

A binary RPM can be built with:

rpmbuild -bb package.spec

The result will normally appear under:

~/rpmbuild/RPMS/noarch/

The -bb option builds the binary package only.

If we also want an SRPM:

rpmbuild -ba package.spec

That is what I will use in CI.

If the computer is doing the work anyway, there is little reason to stop it.

Installing the Packages

A local RPM can be installed through DNF:

sudo dnf install ./package.rpm

The ./ matters: it tells DNF that this is a local file rather than a package name to search for in configured repositories.

DNF then resolves and installs the dependencies.

Which was the whole point of this exercise.

GitHub Actions

Once the spec files live in a repository, rebuilding them manually every time starts looking suspiciously like a task that could be automated.

Tasks like that are dangerous.

They tend to produce CI pipelines.

The workflow can look like this:

name: Build RPM packages

on:
 push:
 paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"
 pull_request:
 paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"

permissions:
 contents: read

jobs:
 build:
 name: Build ${{ matrix.package }}
 runs-on: ubuntu-latest

 strategy:
 fail-fast: false
 matrix:
 package:
 - kde-refugee-pack-minimal
 - kde-refugee-pack-standard
 - kde-refugee-pack-full

 container:
 image: fedora:44

 steps:
 - name: Install build tools
 run: |
 dnf install -y \
 findutils \
 rpm-build \
 rpmdevtools \
 rpmlint

 - name: Checkout repository
 uses: actions/checkout@v7

 - name: Prepare rpmbuild tree
 run: rpmdev-setuptree

 - name: Copy spec
 run: |
 cp specs/${{ matrix.package }}.spec ~/rpmbuild/SPECS/

 - name: Lint spec
 run: |
 rpmlint specs/${{ matrix.package }}.spec

 - name: Build RPM
 run: |
 rpmbuild -ba ~/rpmbuild/SPECS/${{ matrix.package }}.spec

 - name: Show result
 run: |
 find ~/rpmbuild/RPMS ~/rpmbuild/SRPMS -type f -print

 - name: Collect build artifacts
 run: |
 mkdir -p artifacts
 cp ~/rpmbuild/RPMS/noarch/*.rpm artifacts/
 cp ~/rpmbuild/SRPMS/*.src.rpm artifacts/

 - name: Upload build bundle
 uses: actions/upload-artifact@v7
 with:
 name: bundle-${{ matrix.package }}
 path: artifacts/

 - name: Upload binary RPM directly
 uses: actions/upload-artifact@v7
 with:
 path: ~/rpmbuild/RPMS/noarch/${{ matrix.package }}-*.noarch.rpm
 archive: false

 install-test:
 name: Test package installation
 needs: build
 runs-on: ubuntu-latest

 container:
 image: fedora:44

 steps:
 - name: Download kde-refugee-pack-minimal
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-minimal
 path: rpms/

 - name: Download kde-refugee-pack-standard
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-standard
 path: rpms/

 - name: Download kde-refugee-pack-full
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-full
 path: rpms/

 - name: Install refugee pack
 run: |
 dnf install -y \
 rpms/kde-refugee-pack-minimal-*.noarch.rpm \
 rpms/kde-refugee-pack-standard-*.noarch.rpm \
 rpms/kde-refugee-pack-full-*.noarch.rpm

At first glance, this line may look odd:

runs-on: ubuntu-latest

We are building Fedora packages, after all.

A few lines later, however:

container:
 image: fedora:44

GitHub provides the runner, while the job itself executes in a Fedora 44 environment.

There is no need for a separate Fedora runner.

The matrix:

matrix:
 package:
 - kde-refugee-pack-minimal
 - kde-refugee-pack-standard
 - kde-refugee-pack-full

creates three independent builds.

Each spec file is checked with rpmlint, built, and stored as an artifact.

And this is where things become pleasantly convenient.

A normal artifact upload creates an archive containing the RPM and SRPM.

But actions/upload-artifact@v7 also supports:

archive: false

for a single file.

So every binary RPM is additionally available directly as an .rpm file.

No ZIP extraction required.

Like civilized people.

The second job downloads all three build bundles and tries to install the packages on a fresh Fedora environment.

The workflow therefore verifies more than:

the RPM builds.

It also verifies:

DNF can resolve the dependency chain and install all three levels.

And because the workflow itself lives at:

.github/workflows/rpm.yml

while the path filter contains:

paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"

changing the workflow itself triggers another run.

The pipeline therefore tests, among other things, itself.

Summary

A small joke of a task somehow grew into:

a list of programs I will actually use,
three levels of a KDE survival kit,
three RPM metapackages,
automated linting,
automated builds,
an installation test,
artifacts available both as bundles and directly as RPM files,
and a GitHub repository: specfiles.

All because I did not want to type a dozen package names by hand.

It was laziness, Your Honor.

A Window Manager Unlike Any Other

Mon, 28 Sep 2026 19:10:00 +0200

Thirty-three years is a very long time in software.

Trends change.

Architectures come and go.

Companies collapse, occasionally taking genuinely excellent projects to the grave with them.

It is long enough that, back in 1993, I was considering moving from a Commodore 64 to an Amiga 500 — which never actually happened — while in 2026 I find myself interested in software from that same era which somehow still exists.

And not merely exists.

Some of it is doing remarkably well.

In 1993, engineer Robert Nation needed a lightweight window manager for a 33 MHz 486 laptop with just 4 MB of RAM.

At the same time, his work involved analyzing enormous spectrograms, and he needed a virtual desktop larger than a single physical screen.

TWM worked, but it consumed more memory than he liked and did not provide everything he needed.

So he did what any reasonable programmer dissatisfied with an existing tool would do:

he started taking it apart.

The result was FVWM.

Its first public version was bundled with an rxvt release on June 1, 1993. Soon afterward FVWM became an independent project, and it is still with us today.

Despite more than three decades of development, it has retained much of its original character:

it is lightweight, modular, extraordinarily configurable, and assumes that the user may actually know how their own desktop should behave.

F? VWM

So what does the name mean?

Today the official project calls it:

F? Virtual Window Manager

where F? can be expanded into almost anything beginning with the letter F.

Preferably something printable.

Originally, however, the F had a very specific meaning:

Feeble Virtual Window Manager.

Robert Nation himself confirmed this, explaining that the earliest versions offered very few user-selectable features, so feeble was a fairly accurate description.

The software eventually stopped being feeble in any meaningful sense, while the interpretation of the letter F drifted into folklore.

The modern project page suggests words such as:

fantastic, fabulous, famous, flexible…

and wisely leaves the rest to the user’s imagination.

What Exactly Is a Window Manager?

That is a reasonable question.

What sort of software is this?

And why should anyone care?

A window manager manages application windows within a graphical session.

In the X11 world it is responsible for things such as:

window placement,
size,
stacking order,
focus,
decorations,
minimization,
maximization,
switching between windows.

An application creates a window.

The window manager decides what happens to it next.

And that is all?

More or less.

Which is exactly what makes the idea interesting.

GNOME, KDE Plasma, Xfce, and LXQt are complete desktop environments.

They are collections of cooperating components that usually provide things such as:

panels,
menus,
session management,
display configuration,
settings tools,
notifications,
desktop icons,
wallpapers,
device integration,
often an entire set of applications.

A window manager is only one part of that puzzle.

In the old days, an X11 desktop was often assembled gradually.

Need a panel?

Install one.

Need a menu?

Add one.

Want a wallpaper?

Run a wallpaper setter.

Need desktop icons, a notification area, media controls, or animated penguins wandering around the screen?

No problem.

xpenguins is waiting.

Today, we are much more likely to install an entire desktop environment and accept whatever came from the factory.

And the factory keeps providing more.

Increasingly tightly integrated.

Eleven out of ten users never even change the wallpaper.

What Does FVWM Provide?

FVWM is a classic window manager in exactly that older tradition.

Its primary concern is windows and how they behave.

Want a panel?

You can have one.

Menus?

Of course.

A pager?

Certainly.

A window list?

Also available.

But FVWM does not assume that its developers know better than you how all of those things should look or behave.

The default configuration provides enough to get started and then seems to say:

Run me.
Use me.
Decide what is missing.
Then configure it yourself.

That is what its extensive configuration system is for.

The official project describes FVWM3 as a lightweight floating window manager for X11 that can be configured as anything from a small minimal setup to something resembling a complete desktop environment.

Installation

I assume you already have some graphical environment installed.

Modern Linux distributions usually come with KDE, GNOME, Xfce, LXQt, or something similar.

You therefore probably also have a display manager.

In my case, this is Fedora with KDE Plasma and SDDM.

Installation is straightforward:

sudo dnf install fvwm3 dmenu

The first package contains FVWM3 itself.

The second provides dmenu, which the default FVWM configuration uses as a simple application launcher.

It is worth checking that the package installed an X session definition:

rpm -ql fvwm3 | grep xsessions

On my system:

/usr/share/xsessions/fvwm3.desktop

Excellent.

Log out.

Select FVWM3 on the login screen.

Enter the password.

Press Enter.

And…

Hello Darkness

…enjoy the majestic sight of absolutely nothing.

The session did not start.

The reason turned out to be simple:

FVWM3 is an X11 window manager, while my Fedora installation only had Wayland available.

FVWM3 is still primarily built around Xlib and the X Window System.

So Xorg needs to be installed:

sudo dnf install xorg-x11-server-Xorg

Fedora 44 still ships Xorg separately for X11 sessions and software that depends on it.

Ah.

Much better.

Configuring X11

The biggest surprise after all these years is that X11 no longer needs to be configured.

It simply starts.

And works.

There is no need to:

select graphics drivers manually,
describe the monitor,
write Modeline entries,
configure the mouse,
configure the keyboard,
specify font directories.

I remember a time when starting X11 and getting a black screen instead of smoke already counted as progress.

Today it simply works.

Thank you, 2026.

First Start

The default FVWM3 session looks like this:

What exactly are we looking at?

On the right is a panel constructed with the FvwmButtons module.

It contains:

the FVWM logo — still maintaining the cat theme,
desktop buttons 0–3,
a pager,
an area for open windows managed by FvwmIconMan,
a clock and date display.

This is essentially what the current upstream default configuration defines.

As applications are opened, the panel gradually fills up:

That is already quite a lot.

We can even launch something.

Press:

Alt+Space

and dmenu_run appears.

The current default FVWM configuration binds exactly that command to Alt+Space, provided dmenu is installed.

It displays executables found through $PATH.

Which means:

a lot of things.

Far too many things.

Fortunately, the list is filtered as you type.

Windows

The first application window looks something like this:

There is:

a title bar,
buttons on both sides,
a frame,
borders,
corners.

The button on the left opens the window operations menu.

The ones on the right perform more obvious jobs such as closing, maximizing, and minimizing.

Drag the title bar to move the window.

Drag an edge to resize it.

Drag a corner to resize it in two directions at once.

The technology is clearly almost ready for worldwide adoption.

Click the left mouse button on the root window and the main FVWM menu appears:

Not bad.

The important commands are already present.

Including:

Restart,
Quit.

Restart will become extremely useful in future episodes.

Trust me.

Desks and Pages

One of FVWM’s more interesting features is its enormous virtual workspace.

The default configuration provides four desks:

0 1 2 3

Each desk can itself contain multiple pages.

FVWM therefore distinguishes between two concepts:

Desk — a separate desktop.

Page — a position within the larger virtual space of that desktop.

With the normal global multi-monitor configuration, all connected displays together form the visible area of one page.

This means the virtual desktop can extend beyond the complete physical monitor arrangement.

Then you can have several such virtual spaces.

And several desks containing those.

Sounds excessive?

Give it a few days.

You will run out of room.

This becomes especially useful when many windows are open and you want to group them by purpose.

One desk for code.

One for documentation.

One for communication.

One for terminals that have been open for so long that nobody dares close them anymore.

Open a window and try dragging it beyond the current visible workspace.

Near the edge, you will feel a slight resistance.

Keep going.

The window crosses onto the neighboring page.

At that moment the physical screen stops feeling like the desktop itself.

It becomes merely a viewport onto something much larger.

Menus and Window Information

Clicking the right mouse button on the root window opens the window operations menu.

At this point no particular window has been selected.

First choose the operation.

Then choose the target window.

For example, choose:

Identify

and then:

GNU Emacs.

FvwmIdent appears:

At first it looks like a collection of obscure X11 properties.

Later, these values become extremely useful when writing configuration rules.

That is precisely what FvwmIdent is intended for: among other things, identifying a window’s name, resource, and class.

Clicking the middle mouse button on the root window displays a window list, including geometry information.

Its main purpose is to activate another window quickly.

Alt+Tab produces a simpler window list without geometry.

The default configuration binds this directly to FVWM’s WindowList.

Clicking the right mouse button on a title bar opens the current window’s operations menu:

Among the more interesting entries are:

Stick / Unstick — make the window appear across desks, or return it to normal behavior,
Shade / Unshade — collapse the window until only the title bar remains, then restore it.

And that is enough for the first encounter.

Spend a while moving windows around, switching desks, exploring pages, and generally discovering how much space FVWM is prepared to give you.

Then choose Quit from the main menu.

In the next episode, we will log in again.

But this time, into our FVWM.