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
