[xmonad] xmonad, and trends in the tiling wm market

[Thomas Adam]

Hello --

On 08/12/2007, Don Stewart <dons at galois.com> wrote:
> We've not much information on what's happening with tiling wms. One
> source of info is the debian package system's popularity contest: if a
> package is in debian, we get to see a snapshot of trends.

Be careful with that -- the popularity contest is slightly
hit-and-miss and might not accurately reflect xmonad's use.  What is
it you're after though?  A comparison of how many users are
*potentially* (that's the operative word here) are using xmonad?  How
xmonad compares in development to other tiling WMs?  Whether or not
people use it if the moon is waxing as opposed to it being a Tuesday
and the local store run out of meatloaf again?

In my mind, tracking something's use is best determined through
feedback and nothing else.  I've watched xmonad grow for a long time,
and it's quite impressive; much quicker than a lot of other WMs that
have sprung up.  But it's rather late to the party in many respects;
what sets it apart from other WMs is not only the language it's
written in (something of a triumph I'm sure, but not something I care
about frankly), but also its operation of working; it's still
fundamentally different from dwm for instance.

> Here's a little analysis of what's been happening with the tiling wms
> in 2007:
>
>     http://galois.com/~dons/images/tiling-window-managers.png
>
> Summary:
>  *  ion continues long term decline

Yes, understandable.

>  *  ratpoison was in a place to take advantage of ion controversy

Maybe, but then ratpoison's primary goal was to augment GNU screen's
way of working to more than just a terminal, and it's done that
successfully.  It was certainly one of the first WMs AFAIAC to set the
trend for the way other tiling window managers operate.

> Our challenge is to make the cost of installing a Haskell toolchain
> easier, though, so its cheaper to experiment with xmonad. This comes
> down to improved ghc packaging on each distro.

Yes -- there needs to be a more streamlined way of ensuring this, but
like the way Ruby has been packaged in Debian for instance, it can end
up a mess if not handled correctly.  Certainly having Cabal 1.2 in
distros for the upcoming 0.5 release is my main concern.

-- Thomas Adam