by badsectoracula | 2025-07-21 17:37:16+00:00
I've been using (and contributed to) Window Maker for years - in fact it was my first non-DE window manager back in early 2000s. I have used other DEs (most notably GNOME 2 around mid-2000s) and WMs but when i use Linux i always end up back to Window Maker and it has been my main window manager for the last ~10 years as well as the only desktop environment i've been using since ~2021 or so.

Most applications work fine since there is little difference between WMs. That said there are two issues Window Maker has that nobody has fixed:

1. There is practically no RandR support. Sure, you can enable it (and i think it is enabled by default) during compilation but the "support" is really to restart Window Maker whenever the video mode or whatever else changes so that it uses the new resolution. However due to the way Window Maker seems to identify monitors (it seems to use the vertical resolution - probably a hack that worked for someone somewhere around the 90s or early 2000s and nobody bothered to update to use something less hacky) it also causes duplicate dock configurations. Also for some reason if the dock is larger than the vertical resolution anything that doesn't "fit" gets thrown away. Ultimately i've found it easier to just disable RandR support to avoid losing my dock configuration whenever some program changes the resolution.

2. While there is EWMH support, either there is some bug with how some parts are implemented or (most likely) there are subtle differences between Window Maker's implementation and other window managers (e.g. IceWM) that applications assumed would work like that cause issues with Window Maker. The most obvious of those is applications that want to "take over" window management and handle moving and resizing themselves - it either doesn't work (the applications do not move) or the move/resize happens erratically (e.g. Firefox with the titlebar disabled or Steam has this issue). Also many applications do not get the frame size (this is probably some race condition because Window Maker does set the frame size hints properly) correctly, causing them to get wrong sizes and when combined with them trying to handle sizing and position themselves, they can end up flickering by constantly trying to set the "correct" size and/or moving and sizing themselves whenever their UI updates (often becoming smaller and smaller because they assume some frame size of 0). This is most common with applications running under Wine, but some other applications have issues too because of that (e.g. Virtualbox).

I've tried to figure out the #2 (for #1 i just don't care that much since i'm using a single monitor anyway) but from what i could tell Window Maker seems to be doing everything properly. I didn't spent that much time on it though. At some point (and assuming nobody else does, though it has been like that for years) i'll try and compare what Window Maker does and what IceWM does (which works fine) and where their behavior differs. My guess is some race condition, perhaps Window Maker sets the hints too late or something, though this is just a guess. I'll need first to write a small X11 program that replicates the issue.

As a workaround for #2 i've been using a feature i added to Window Maker years ago to ignore any decoration changes for windows (it is in Attributes -> Advanced Options -> Ignore decoration changes), essentially forcing all windows to have a resize frame and titlebar, ignoring any requests for hiding them. This lets me move around and resize, e.g., Steam (and also use all window management functionality that Window Maker provides - like rolling the window up/down using the mouse wheel - instead of whatever Valve thought i'd need).

One other issue with Window Maker (though it isn't really a Window Maker issue per-se) is that since Window Maker is not a (desktop) compositor, Gtk4 applications that assume a compositor will use black colors for whatever would be beneath a window - this mainly means that popup menus with rounded corners will actually get black corners. This is really a side-effect of Gtk4 assuming a compositor is there and not having a fallback for when there isn't one and would be an issue with other window managers too, but it should be solvable (if you care about it, i don't) by using a dedicated compositor (i think compiz or something like that may work).