[xmonad] Small announce about the completion of the bluetile merge

[Spencer Janssen]

On Mon, Dec 07, 2009 at 05:43:29PM +0100, Jan Vornberger wrote:
> Joachim has already touched on the question of releasing a new version
> of xmonad and xmonad-contrib, so that Bluetile can depend on them. That
> would be my next question as well, as that would allow me to get rid of
> the bluetilebranch-stuff on hackage.

In the past we've saved all new features for major releases, with these
releases fairly far apart.  The next major release of xmonad is 1.0, which
is potentially months away considering some of the things we have in mind.
My hunch is that you'd rather not wait so long.

What I propose that we break with precedent a bit and make a 0.9.1 minor
release with new features.  For a while we've talked about making contrib
releases independent of core, now seems like a good time to start.

We could make a minor release as soon as 1-2 weeks, with more releases
on a monthly basis as needed.

> But before that, it might be good to get a shared understanding of
> how Bluetile's future should look like.
> 
> I think some people feel that Bluetile should just be completely merged
> into xmonad-contrib and cease to exist as a separate project. I can
> understand why they would like to 'tidy' things up, but I have to say
> that I think that this approach is completely incompatible with
> Bluetile's goals.
> 
> Burying Bluetile somewhere in xmonad-contrib isn't my idea of a 'gentle
> learning curve'. Even if it becomes as easy as writing
> 
>   main = xmonad $ bluetileConfig

Yes, as a practical matter Bluetile needs to be a 'cabal install' or binary
package manager invocation away, no other configuration required.

> If it indeed stays as a separate project, the only question is how much
> code remains only in Bluetile's repository. For now I have moved pretty
> much everything over to xmonad-contrib, except for a few things:
> 
>   The Bluetile dock application - this is very specific to Bluetile's
>   config, so not really very flexible. It also requires gtk2hs. So I'm
>   not sure it makes sense to put this in xmonad-contrib. It would add
>   gtk2hs as a requirement to xmonad-contrib.

Yes, we shouldn't depend on on gtk2hs in contrib.

>   The module BluetileCommands. This is pretty much just a list of
>   hard-coded commands that are passed to ServerMode to give the dock
>   a way to control Bluetile.
> 
>   The module BluetileDock. This writes status information to a pipe so
>   that the Bluetile dock can receive it and display things like the
>   current layout etc.

The inclusion of these depends on whether it is feasible to run the dock
outside of a Bluetile session.  If this is possible and desirable, they could
be included in XMonad.Config.Bluetile.  Otherwise, if the dock is very closely
tied to Bluetile, then these modules should be in Bluetile rather than contrib.

>   Bluetile's actual config, making use of these three things and
>   Bluetile-related stuff from xmonad-contrib.

Could this, or a slightly stripped down version of this, be in contrib?

> It seems like a good division to me, because all the very
> Bluetile-specific stuff is in the Bluetile repository and the
> more-or-less reusable modules have been moved over to xmonad-contrib.
> 
> But maybe it would be a good idea to provide XMonad.Config.Bluetile in
> xmonad-contrib for someone who wants to move from Bluetile to xmonad
> proper and start out with the same configuration - albeit without
> Bluetile's dock.

I do think we ought to have XMonad.Config.Bluetile.  I'm certain that at least
some Bluetile users will want to configure it a bit, so we'll need an upgrade
path.


Cheers,
Spencer Janssen