Other Screenshots of BSD Window Managers for X11

In another Window Manager, it took me a few months to stumble on the answer to some of this.
This is the problem. Also for twm one needs to learn and discover it by carefully reading the man pages.
This is the reason because I do not use cwm, I never found the time to learn it. Also the reason because
I do not use fvwm in FreeBSD: it is not nicely configured like in OpenBSD and I do not know how to
configure it. But fvwm is too big.

jwm seems not to have a big screen like vtwm or fvwm, but 4 (or more?) independent desktops. Perhaps
it is like cwm with its grouped windows? It is a different principle.
From vtwm manpage
f.move This function drags an outline of the selected window (or the
window itself if the OpaqueMove variable is set) until the in-
voking pointer button is released, at which time the window is
raised (subject to RaiseOnStart, MoveDelta, and NoRaiseOnMove).
Double clicking within the number of milliseconds given by Con-
strainedMoveTime warps the pointer to the center of the window
and constrains the move horizontally or vertically, depending
on pointer movement. To abort the move, press another button
before releasing the invoking button.

Moves a window (or possibly the real screen) inside the desktop
display. To abort the move, press another button before releas-
ing the invoking button. By default, the bindings using the
desktop context are defined as:
Button1 = : desktop : f.movescreen
Button2 = : desktop : f.movescreen

This is useful if you want to reset the default keyboard and
pointer bindings via NoDefaultMouseOrKeyboardBindings and use
some of your own for the virtual desktop, e.g.:
Button1 = : desktop : f.movescreen
Button2 = : desktop : f.warp
Button3 = : desktop : f.iconify

This function is not useful under any context other than "desk-

f.panelmove geomstring
This function moves the selected window to the location denoted
by the extended geometry specification geomstring as described
in IconManagerGeometry. Geometry aliases left, right, top,
bottom (e.g. "left@pointer", "top@1", etc.) denote the window
is to be moved and aligned to the left, right, top or bottom
edge on the specified target panel. A relative shift by (X,Y)
of the selected window can be specified by "[01]x[01]+X+Y@P"
analogously to the description in f.panelzoom below.

f.panelzoom geomstring
This function enlarges the selected window as denoted by the
extended geometry specification geomstring described in Icon-
ManagerGeometry. Accepted are left, right, top, bottom, verti-
cal, horizontal, full and maximize as geometry aliases in order
to perform a zoom operation analogous to f.leftzoom, ...,
f.maximize but restricted to the target panel specified by @P
of geomstring.

The non-aliased geometry string is used to denote relative zoom
by (X,Y) pixels and has the form "[01]x[01]+X+Y@P", i.e. W, H
having values 0 or 1 denoting if the X or Y component (or both)
is to be considered in the following zoom operation. If X (or
Y) is positive, the right (or bottom) edge of the selected win-
dow is moved that many pixels to the right (or bottom). If X
(or Y) is negative, the left (or top) edge of the selected win-
dow is moved that many pixels to the left (or top) accordingly.
If X (or Y) is zero, then the corresponding window edge, left
or right (top or bottom) depending on the '-' or '+' of X (or
Y), is taken to the appropriate panel edge. The special value
"-0-0" of geomstring can be used to restore the original window
size and location after repeated execution of the geometry-
based zooming. Analogously "+0+0" overwrites the saved origi-
nal size/location with the current values of the window size
and location. (For values e.g. "0x0+0+0@next" the window is
only moved to the specified panel without changing its size,
keeping its relative location as on the source panel if possi-
This information is difficult for me to understand and implement, as I don't see the connection between that and trying it with my mouse (which it seems the bindings can be adjusted to be keyboard). This is something that needs more focus in a topic for window manager caveats.

On most window managers, the number of workspaces can be adjusted. I usually adjust mine from 4 to 2. In my JWM screenshot as well as other screenshots, I have 2 workspaces. On a few there's 2 workspaces on 2 monitors, where 2 monitors are on each workspace.

JWM has grouped windows. To access specific menu options from each process within the group, I'll right-click an application group in the taskbar, and right-click again so more options show up to the specific running application.

polybar, conky, alacritty (in background)


polybar, conky, dzen

Last edited:


I'm planning to do it when I finish some minor changes but overall looks exactly the same[1]. In regards to experience, this something between x11/i3 and x11/dwm with some x11/bspwm influence but this is a relatively product and still is green, and soon a major code refactor should land too.

[1]except I'm not using conky because of a annoying bug (just a few people suffer).

Here is ctwm (x11-wm/ctwm). The configuration of these twm derivatives always daunted me, but my config is starting to take shape with a few growing pains. This is a serious BSD-compatible alternative to fvwm and is more like a successor to twm instead. Even NetBSD uses it now!