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

[Wirt Wolff]

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.
>
> <snipped justification I agree with, wmw>

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