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