Excerpts from Jan Vornberger's message of Mon Dec 07 09:43:29 -0700 2009:
But before [releasing a new xmonad and contrib usable as a base dep for bluetile], 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
in your configuration, it still is too difficult for the target audience I have in mind. I think of Bluetile as an interactive tiling window manager demo. I want people to be able to just say to a friend: "hey, if you want to get a feeling for twms, check out Bluetile." They 'apt-get' it (hopefully, in the future :-) ) and can play around with it - no documentation needed. If they get hooked, they can later move on from toy-Bluetile to full-blown-xmonad-proper.
Yes, agreed, providing bluetile only from within xmonad/xmonad-contrib plus some bluetile flag activating the dock, etc. isn't the way to go.
So I think it's better to have two different 'brands', so to speak:
Bluetile = interactive tiling window manager demo for someone who wants to play around with a TWM but has little time or incentive to do much configuration or read documentation. It makes the necessary trade-offs to lower the entry barrier as much as possible.
xmonad = powerful tiling window manager framework which can do everything Bluetile can do and more, for those who are willing to put in some configuration effort.
Those are the reasons why I feel Bluetile should continue to exist as a separate project. How do others on the list feel about this?
I strongly agree. Bluetile should be runnable as a self-documenting application not needing ghc to be installed, in fact not even being configurable except through its own interface. As Jan has stated from first design goals: (for its target audience's needs) its defaults should be so usable that there is no need to modify or customize it. For people who do want to customize, or miss functionality not provided by bluetile, there is xmonad and contrib.
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.
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.
Bluetile's actual config, making use of these three things and Bluetile-related stuff from xmonad-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.
This makes sense to me, with the possible exception of BluetileCommands. I suspect that many of them would be useful for people using, for example, dzen clickable areas or other server mode interfaces. Perhaps BluetileCommands should only include the server mode commands which require the bluetile dock or greeter, and the others should be imported from a pre-configured command set available in 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.
Yes, I think this its very important to provide an easy way to activate as many bluetile features as possible in one go from contrib. Already people are interpreting the announcement to mean "install darcs xmonad and turn on bluetile to try it out." But this is a short run, temporary confusion. By the time of the proposed next xmonad release there should be plenty of clarification already sent out as to the differences in goals and function for each project. In the long run there are plenty of other benefits to providing a "bluetileConfig". As Jan points out it's key to have a simple easy migration path for bluetile users. But also there is much pent up demand for better stacking and mouse manipulation even from long time xmonad users, and certainly from people exploring different tiling managers or coming from awesome or fvwm, etc. A bluetileConfig could also play a role similar to the template config in providing a reference for people picking and choosing parts of the bluetile configuration, or wanting to activate them all plus a few customizations. Thanks for bearing with the long-winded saying of: * Yes I agree they should continue as synced separate projects. * Some of the bluetile server commands should be available from contrib. * There should be a bluetileConfig providing all but the dock and greeter bits from bluetile. As much as possible normal Config.Foo customization methods should work, and any deviations be well documented and include integration helper functions if needed. regards, -- wmw