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