FreeBSD Desktop – Part 4 – Key Components – Window Manager

In the next parts of the FreeBSD Desktop series I would like to describe key components of self made custom desktop environment such as:

  • Window Manager
  • Status Bar
  • Task Bar
  • Wallpaper Handling
  • Application Launcher
  • Keyboard/Mouse Shortcuts
  • Locking Solution
  • Blue Light Spectrum Suppress

To not make the posts huge today’s article would focus on the first component – the Window Manager. In the next series each of these components configuration would also be described along with eventual needed scripts.

You may want to check other articles in the FreeBSD Desktop series on the FreeBSD Desktop – Global Page where you will find links to all episodes of the series along with table of contents for each episode’s contents.

Window Manager

We will use Openbox, it was already installed in previous part of the series. Why Openbox and not something else? I do not have any exact answer that will make you feel that its the best possible choice. The arguments for it are:

  • It has good official documentation.
  • Lots of online materials/howtos/blogs about it.
  • Used as Window Manager in many Desktop Environments.
  • Very fast and very low on resources (written in C language).
  • Can support tiling with external utilities like or pytyle.
  • Fully compliant with EWMH (Extended Window Manager Hints) Standard.
  • Fully compliant with ICCCM (Inter-Client Communication Conventions Manual) Standard.
  • Allows generating dynamic menus with scripts.
  • Chosen as Window Manager of the Year by Members Choice Awards.
    • In 2015 with 23.98% of all votes.
    • In 2016 with 24.04% of all votes.
    • In 2017 with 24.22% of all votes.
    • In 2018 with 24.64% of all votes.
  • Can look really awesome, several examples below.

The Axonkolorish Openbox theme.

The Mint Openbox theme.

The TWM Openbox theme.

The Violetgrey Openbox theme.

You may also want to check other categories of the Members Choice Awards from the last 3 years. You may find solutions and applications that You never knew existed.


The Openbox memory usage on my system is about 25 MB of RAM. The total CPU usage is also very low as these 45 seconds are from more then one day of using system along with suspend/resume usage.

50467 vermaden        1  20    0 37724K 26116K select  0   0:45   0.00% openbox


I will not describe here all possible Openbox configuration options, the future series would contain setup that seems to work best for daily use (at least for me). If You would like to increase your knowledge about Openbox then check the official documentation and other online resources such as these:

If somehow you will not find Openbox usable then You can try Fluxbox or PekWM. I have used Fluxbox for years and it also served very well all that time.


Someone once told me why I moved from Fluxbox to Openbox … or why I did not used PekWM which is also similar in concept. There were ‘small’ things but pretty annoying ones. Below are differences between Openbox and Fluxbox and PekWM that I wrote around 2010 and 8 years later they are still true. It was mostly those icons scaling and ‘margins’ for the desktop that Openbox offers and other small things. But Openbox configuration in XML was a pain at the beginning.

Window Switching Behavior

Proper ‘ALT-TAB’ behavior is only available on Fluxbox and Openbox. PekWM lacks a lot here, check this for more information –

While Fluxbox switches between windows instantly, Openbox/PwkWM can show list of windows while switching and Openbox can also show black/white border highlight for every window (like Metacity from GNOME 2).​

Workspace Menu

The so-called workspace menu in Fluxbox expands into submenu for each workspace, which makes its useless for fast general usage.

Both PekWM/Openbox provide workspace menu that shows all apps on all workspaces instantly without any submenus, but only Openbox can render all application icons properly here.​

Proper Icon Rendering

Both PekWM/Fluxbox cannot render application icons properly, while Openbox can. Fluxbox renders properly icons in the root menu, but only if you select exact size for the icon (same as actual image size), if image is bigger, its scaled version would be ugly, even when downsized from pretty large image.​

Working Area

At both Openbox/PekWM we can set margins for the workspace, the space on the sides which will NOT be used for windows. To achieve the same on Fluxbox you can only use dome DockApp with displaying transparent PNG file (dirty hack) with do not maximize over slit option. but its only for one side of the desktop, not all of them like in ​Openbox/PekWM.

Actions on Window Bar/Border

At PekWM/Openbox we can define various actions that will happen when clicking/scrolling the window border/bar, some custom commands (like transparency increasing/decreasing with transset-df command), Fluxbox does not offer that​.


Both PekWM/Fluxbox are NOT fully compliant with NETWM/EMWH while Openbox is (but I never suffered from the fact that they aren’t fully compliant).​


Both PekWM and Fluxbox are written in C++ while Openbox is written in C, which makes it little faster, but its probably hard to notice this on Core 2 Duo class machines these days.​


Both PekWM/Fluxbox support tabs in windows, but I do not remember when I last used them πŸ˜‰ From these two Fluxbox also offers taskbar, but being frank with you, I must say that having so nice workspace menu on Openbox I do not need taskbar any more.​

Command Subshell

If you put something with subshell into Fluxbox root menu – $( ... )Fluxbox will execute that without any problems, while Openbox will throw an error (haven’t checked for PekWM). Same for the alternative ` ... ` syntax.

There are my thoughts on differences between these three WMs.