[xmonad] tabbed and the way the new decoration framework works

[Andrea Rossato]

Hi,

Spencer just pushed a big patch to clean up my code a bit. He also
broke Tabbed, since, probably, I was not quite clear on how the new
decoration framework works.

A decoration is a modification to a layout, now. And it is attached to
a window. If there is no window, there is no decoration.

This way we can decorate any window by just applying a modifier to a
layout. This is done safely, since the modifier implementation as a
layout (ModifiedLayout) is abstract, and we can guarantee that the
ModfiedLayout behaves exactly like a Layout. By the fact that layouts
may be modified only by layout modifier, we can be sure every modified
layout will have a predictable behavior.

There is a price to pay. If we want the decoration framework to be
independent from the layout framework, we can decorate only windows
returned by a layout.

This means that a tabbed decoration will create tabs only for windows
that have been returned by the underlying layout. Otherwise we must
create a layout.

So you choose: a layout or a layout modifier. They have different
semantics.

The LayoutModifier class together with the ModifiedLayout instance of
the LayoutClass will perfectly map a modifier to the layout behavior,
but they are different things.

As you may understand this is the very very reason why I'm asking to
change decoration :: l a -> String to decoration :: l a -> X String.

If we have the second type I can write a LayoutCombinator class with a
CombinedLayout that will perfectly map the semantics of a Layout. Pure
and impure combinators will thus behave as layouts.

If you do not give me that type, I'll be able to write a class the can
map perfectly only pure combinators, and quite well impure
combinators. This is a choice we can make: we like l a -> String? Ok,
I'm going to write a pure combinator class only.

As a side effect I'll stop maintaining (bugged) layout combinators
that break at every API change.;)

As I said, this is a change that has some quite deep implication. I
tried to write extensively on that, *without* feedback from the other
developers (well I had a go from David, who started all that). If you
don't like this design we can quickly revert it. I don't really mind.
It has been a pleasure this ride into type classes, because it gave me
a completely new perspective on how extensible code must be written. I
would like to thank David for that, since he pushed me in this
direction. But I can understand that maybe the other developer may
just think David's the one to blame... Wait! No, I take full
responsibility!
 
Cheers,

andrea