Thomas Adam <tho...@fvwm.org> writes: > Hi, > > I need to send these out publicly so that whomever steps up to the plate to > run with this has an idea what needs to be done, and what that person it > letting themselves in for. I've also been asked privately for me to > indicate areas of interest for anyone thinking of hacking on FVWM in the > future. > > First of all, understand that FVWM [1] is over twenty years old. A lot of > the workarounds are interesting and some still relevant today. But not all. > Many of the hacks/workarounds, etc., you may come across in FVWM hail back > to a time when applications were all too literal in their use of the ICCCM, > yet we see no such applications in heavy use today (Tk is a good example > here). > > That's small-fry compared to a lot of the design decisions FVWM is founded > on. It's not surprising really, FVWM being so old means that things like > NETWM (later called the EWMH) was bolted on to FVWM's already doctrine > support of the ICCCM, without thinking about core data structures, etc. > Over time, this has lead to "organically grown" data structures, making > future expansion/changes difficult to impossible without there being some > very intrusive changes needed. Xinerama support is another good example of > this---we see users who are crying out for per-screen workspaces, but > implementing this is very hard [2] without a rewrite of FVWM. > > And I think that's the point here---there's only so many band-aids you're > going to be able to apply before FVWM starts to creak at the seams. FVWM's > reached the point where it needs to be rewritten, its core data > structures/APIs reconsidered, for instance:
Over the years, lots of cruft has been removed. I remember doing a few surgeries myself. We had the "great style rewrite" that permanently cured adding more style flags. I don't have to defend the organizational state of fvwm, I don't have another WM that supports so much stuff to compare it to. But when changes are made, developers are expected to reorganize as required by the change, just don't tack weird things on. Of course how well that's done is always a matter of opinion. > * Switching to XCB to avoid all the passive server grabs, etc., FVWM has > had to do to workaround problems. There's other benefits here, but > that would centralise those "hacks" in FVWM up to the library in this > case; less code; Just read about it. At work I support a bunch of people using Fvwm on Solaris. They'd be left out in the cold. We hear from AIX users once in a while too. Don't know if its there but I suspect not. If I'm reading right, Hummingbird Exceed is okay. Still if available for enough users, sounds like it might help. I don't think I'd be motivated though, Fvwm key bindings work pretty well for me. > * Reconsider support for XPMs in FVWM, and have one image format; > perhaps just SVG? The image-loading routines found in lib/ no longer > need to be as portable as they are; Hey, our old icon package is all xpm files: http://www.fvwm.org/download/icons.php Not that we can't fix that. Also a load my my icons are xpm. I've been around too long. > * Ditch the Xinerama SLS support (implied by a move to XRandR outright); Need someone that wants XRandR bad enough. I tried rotating my 21" 1600x1200 and it was interesting, but display slowed down a lot. Couldn't live with that. > * Consider using DBus as the API which is used to communicate to/from > FVWM, INCLUDING MODULES; Is it available on all X Windows platforms? Is it faster than the pipes we use? > * Go with a saner config file format---don't hand-roll your own. This > was fine back in 1993. JSON might be a good choice here; > * Unify commands and their syntaxes. This epitomises FVWM's fault by > providing the same functionality X number of different ways through Y > number of commands. Be consistent in the commands you use; their > syntax, and their context; > o This would do away with the need for functions/conditional > commands as well; I'm pretty much for keeping Fvwm compatible release to release as much as possible. > * Consider relicensing to something other than the GPL; maybe > a dual-license? The *BSD guys love FVWM. Seriously. I'd have > dearly liked to have gone back to FVWM being BSD-licensed, but > couldn't for obvious reasons; Yeah I think we're staying with GPL. It's never made much difference. > That's more blue-sky thinking. The immediate goals should be for you to > switch to Git and shove the thing on Github. Per-project hosted sites are > not going to cut it in 2013, chaps and chapettes. Really. Get yourselves > noticed, and go hang with the cool kids. Sure, you could make git.fvwm.org > authoritative, but at least have an official mirror on something like > GitHub. It's where projects are noticed nowadays. You can create > organisations therein and list members; might make the CVS permissioning > scheme in use obsolete, thank God. If we move our source, we would still need Jason for accepting release binaries, and we'd need to update CVS to get our web pages updated. So, I think a Git transition would necessitate moving the entire project, web pages and all. I'm not sure what all the steps are but I've been thinking of buying some web space. Any comments? > Note that this isn't anything personal or an attack on past contributors--- I don't see an attack. > I think we (as in developers) have long since realised FVWM3 was meant to be a > rewrite. It didn't happen. Fair enough, but it's going to quickly turn > into a curio if it's not maintained past the point of applying band-aids. > The world's moving on with things, and FVWM isn't. I was never in favor of Fvwm3. Too many projects dump old and working forcing their users through a conversion. > [1] By all rights it's meant to be written as 'fvwm'. I personally > disagree with this, since it's an acronym, but whatever, the style is > already completely destroyed. Don't care. -- Dan Espen
