2013/9/24 Dan Espen <des...@verizon.net>: > 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.
I like the possibility to use raster OR vector graphics. The pool of SVG files are significant smaller than PNG or XPM. Also it is easier to create a raster than a vector image. This is one of FVWM's big plus points :-) >> * 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. Hmm ... haven't discovered this yet ... I've experimenting much with XRandR and FVWM. For me the main disadvantage is that you need a restart of FVWM to handle XRandR changes (e.g. resolution) whilst other WM's can do this on the fly. >> * 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. Only the project would needed to move. It's sufficient to make links to the tags (releases). Github creates for each tag a tar.gz/zip file. Another possibility is to use sourceforge as the new home. It has a better infrastructure than Github (download controls, Blog, its' own newsletter, etc). And it supports git, too. > I'm not sure what all the steps are but I've been thinking of buying > some web space. Any comments? First of all it has to be discussed how a new infrastructure could looks like. And, if we are willing and have the manpower to do this step. >> 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. Sooner or later X will be replaced with Wayland. From that point of view FVWM3 should use the reference window manager implementation Weston as a new base. As Wayland has a stable API now we would have time to develop FVWM3 before X will be replaced (I think this will take 2 or 3 years). The only big problem is ... who would participate on this huge project ... With 2 or 3 people it's impossible because we're all workers mostly with families ... >> [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. It is like others: KDE -> Kde GNOME -> Gnome XFCE -> Xfce ... It is regardless how the name is written. Important is for what it stands for. Best, Thomas
