> It's a pity no one ever tried to replace the WINGs widget set with actual GNUstep
It was by purpose at the beginning. Window Maker suppose to be lightweight window manager which resembles nextSTEP, nothing else. GNUstep people has decided to adopt wmaker as their window manager, not other way around.
I'm still using wmaker starting from late 90s (also had couple minor contributions)
> 1. There is practically no RandR support.
It is awkwardly implemented yes, as internally wmaker will restart, although changing resolution works for me most of the time. Wmaker doesn't identify monitors, it talk with xlib to get the layout when new display is detected or removed.
As for double dock - never have double dock issue. Sometimes I ended up with lossing it's configuration, especially in a cases when resolution set for the display is too low. That might happen when no display is detected/connected, then resolution is set to 64x64 pixels by X.
> 2. While there is EWMH support, […]
It's partially implemented, and indeed it lacks of handling self-managed application. Some apps are working fine (AFAIRC GTK3 based) and some don't (steam client), but in general for those which are not cooperate modifier key can be used to move such window around and keyboard shortcuts (which I'm mostly using anyway) to resize. Or to force window to use wmaker decorations as you mentioned.
This issue I've tried to solve couple of years ago[1], found culprit, but I've failed to do so. I've also spend a large chunk of time to compare it with PekWM, where those things are working as intended, but stuck on event handling.
As for composition. You might consider to use standalone one (xcompmgr, compton, picom, etc) just to get the effects.
> Wmaker doesn't identify monitors, it talk with xlib to get the layout when new display is detected or removed.
It'll restart if anything changes, but the problem is...
> As for double dock - never have double dock issue. Sometimes I ended up with lossing it's configuration, especially in a cases when resolution set for the display is too low.
...that it attempts to create different dock configurations based on the monitor height (you can see that if you check the configuration file). This is something that would make some sense in a pre-Xinerama world where Window Maker would be launched for each monitor, but it doesn't make some sense post 2000s and is really just some ancient hack that nobody bothered to fix.
> It's partially implemented, and indeed it lacks of handling self-managed application.
AFAICT the support is there, but some applications seem to assume some additional de-facto behavior that Window Maker does not have. Initially i also assumed the support wasn't there and i went into implementing it myself, only to find out that it is already implemented - and seemingly works as the spec describes.
> ...that it attempts to create different dock configurations based on the monitor
it will create dock based on the new display IF the new display is the primary one. You can have displays in different resolution, and it will work. I'm using dual monitor on daily basis and occasionally connect additional one, and didn't get "dual dock" for years. Let me stress it again - dock conf will get messed up, if resolution for the display is smaller then current dock height.
> I'm using dual monitor on daily basis and occasionally connect additional one, and didn't get "dual dock" for years.
I think there was a misunderstanding here, i wrote "duplicate the dock configuration", not that there was a "dual dock" on screen. Basically if you open `WMState`, under the `Dock` node you'll see something like `Applications { ... }` but also an `Applications<height> { ... }`.
The reason being that Window Maker uses the current screen height to identify which dock to load/save by attempting to load `Applications<height>` and if there isn't such an entry (it doesn't try other heights), it reverts to `Applications`, if any or just destroys the dock.
This behavior (which has been here since 1999[0]) combined with restarting whenever RandR restarts means you get to lose your dock setups whenever the resolution changes. Or if you want to be more generous, you get to use a different dock per resolution.
Which is why i do not have RandR compiled it.
> Nope [1]. Not for those message types.
Yeah, sorry, i meant _NET_FRAME_EXTENTS for calculating frame size, which causes issues with Wine and some other applications.
> I think there was a misunderstanding here, i wrote "duplicate the dock
Oh, right. For me it will always be messed up dock conf, when resolution of the screen, where dock resides, will be lesser than actual dock height. I guess that thing deserve a bug report. I bet most of users would expect to have dockapps preserved even if those are out of reach because of screen size.
> Yeah, sorry, i meant _NET_FRAME_EXTENTS for calculating frame size,
That's true.
FWIW even with those annoyances, wmaker is still usable. The only things which manifests to me are virtualbox trying to fight wmaker in window placement and steam launcher which lacks of ability to move around with mouse (without modifier key).
TBH, I'm pretty happy with it, perhaps my workflow plays a role here, as I'm rather keyboard person, and mouse is used mostly on web browser.
There was a time, when I was so fed up of the Calibre being so bloated, while all I needed was just a convert capabilities, that I started to rip off parts of the Calibre, clean it up, make things simpler, removing unnecessary things and trying to understand what is happening behind the conversion, resulting with ebook-converter[1], which simply do the conversion, without all the management/downloading rss/editing/what have you. It is usable right now, but I'd say it's still somewhere in between alpha and beta stage. You could give it a shot.
looks like an interesting project... but I must admit it's not really something I use or need anymore. I used to do some book conversions when I would only find (say) a `azw` or a `mobi` file and would need to convert to `epub` but these days (a) I just find a `epub` but even if not (b) koreader can read `mobi` files and a lot more i can throw at it and (c) `azw` files are basically unconvertible, if I followed that correctly.
I own really old ebook reader, but it still works (Sony PRS-505), so mine intention was to be able to easily convert to BBeB/lrf format, which is fastest on this reader. And no, I didn't bother to find out if drm can be removed from the ebooks - perhaps the reason is, that I'm always looking for drm-free ebooks. Although, I don't mind if anyone want to implement that and contribute.
It was by purpose at the beginning. Window Maker suppose to be lightweight window manager which resembles nextSTEP, nothing else. GNUstep people has decided to adopt wmaker as their window manager, not other way around.