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:

    * 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;

    * 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;

    * Ditch the Xinerama SLS support (implied by a move to XRandR outright);

    * Consider using DBus as the API which is used to communicate to/from
      FVWM, INCLUDING MODULES;

    * 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;

    * 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;

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.

Note that this isn't anything personal or an attack on past contributors---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.

-- Thomas Adam

[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.

[2]  The prerequisite here is XRandR support; Xinerama must die.  I
prototyped this before, and found the change so very difficult I abandoned
it because it was more or less TFVWM (Thomas' FVWM) at this point, not
something I wanted.

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Reply via email to