Alternative XServers and fvwm
Thomas Adam <[email protected]> Sat, 21 Jun 2025 19:24:33 +0100
| Newsgroups | gmane.comp.window-managers.fvwm.devel |
|---|---|
| Message-ID | <2nunzdfnq7tjob27hghg42rr3kc6p4yi5kw2cbyzj6apsq3ukf@lxauv7e6nx3v> |
Hey everyone, I hope you're all well. I know things have been quiet: Dominik, Dan, etc., I hope you're both well and things are looking up for you both, post-covid. I was doing some digging, and noticed the following check in fvwm/fvwm,c which enabled a bugopts workaround for raising clients: "Hummingbird Communications Ltd." "Network Computing Devices Inc." "WRQ, Inc." If we detect the above XServers, we enable this workaround, which appears here: https://github.com/fvwmorg/fvwm3/blob/6000175467fada5d5329f2ecf9e1c0b99937b3ce/fvwm/stack.c#L1038 Does anyone have any additional information as to why this was necessary, and what was it above the above XServer implementations whih meant they all had the same "bug"? I just find it really interesting that fvwm seemingly worked around this. I've looked as other WMs, such as TWM, which tells me that this workaround happened afterward, although I can't see any other WM implementing a similar fix. I know fvwm was a reference for a given standard at the time -- heck, the code is littered with workarounds for TCL/TK applications, where ConfigureNptify was a continual issue. If anyone has any additional information on the above, I'd appreciate. I've also asked Mastodon if they know anything: https://bsd.network/web/@thomasadam/114722333161890837 Thanks for anything you can tell me! Thomas