Some of you may be thinking I'm just rewriting Ion3 in Haskell... my screen shots could even lead you to think I'm *not* using xmonad at all...;) This is just because I've been using it for quite some time and I came to love some of its features. And so I wrote the prompt and I contributed in improving David's tabbed layout (well, I also contributed in breaking it, when I added an amazingly inefficient way of managing fonts). The last thing from Ion3 I was really missing was the floating layout. *That* floating layout (and *not* our floating layer). I wanted it because I need it in some places of my desktop. Since no one was going to write it in the near future I decided to do it myself. I thought it could also be an opportunity to refactor a bit Tabbed and clean up its code, which was quite ugly (I wrote it and so I know!): it was the first or the second layout ported to the new class system. There was a problem: the ugly part in tabbed is the decoration windows management stuff, which requires a state to keep tract of created windows, the font structure (loading fonts is very resource consuming, I was told), and so on. If I were to write the floating layout I should replicate all that code, debug both versions, maintain both versions, etc. I thought it wouldn't be manageable. Then I had the idea of applying the same design pattern we have been using somewhere: generalize a computation and fine tune it with a type: our event handler uses a type of the LayoutClass to ask him to perform some specific tasks needed for a specific layout (handleMessage); Operations.windows uses a type of the LayoutClass to perform some specific layout related tasks (doLayout); the ModifiedLayout instance is fine tuned (or controlled, or driven, I just don't know the word that should be the more appropriate here) by a type of the LayoutModifier class - even xmobar has been conceived this way (a plugin is just a type member of the Runnable class, if I remember the class's name right)... This is how I conceived Decoration and the DecorationStyle class. Now, it seems to me some are complaining because Decoration is broken. And the prove Decoration is broken is given by the fact that the tabbed layout they are using is not what they expect. And since that tabbed layout is not what they expect, they think that tabbed layout breaks other part of the system (smartBorders, for instance). I would like to point out that the working of Decoration and the tabbed layout *may* be unrelated. Decoration is similar to the old tabbed layout, but just because I used the old tabbed layout to design the abstract computation to be performed for decorating windows. But Decoration *doesn't" enforce *any* idea of a layout. It is just an abstract way of creating decoration windows, and that abstract way is made concrete by a type of the DecorationStyle class. Only after that, there is the problem of the specific behavior of a tabbed layout. I would like you to admit, as I do, that there *may* be different ideas of what a tabbed layout is. Many of you think that a tabbed layout is a focused window and a set of tabs representing non visible windows belonging to that workspace. While I think this is a legitimate vision of a tabbed layout, I would like to point out that it is totally inconsistent, since it would require the focused window *not* to have a tab. Instead, tabs represent both unfocused windows *and* the focused one, and you need to use colors to avoid confusion. Since I come from the humanities, I have a totally different perspective: a tabbed layout is like an index-book (if you get what I mean - I'm using an Itaian/English dictionary here...;) or an address book, if this is giving you a better idea. Now, I understand that your idea of a tabbed layout is more convenient, since it makes it easier to code other part of the system, such a smartBorders (I know that if I put it this way you may have the feeling that I'm thinking your idea of a tabbed layout is an ugly hack to quickly code smartBorders, and the rest. And you may even be right...;-). The problem is that you are enforcing it in the wrong place. By enforcing it in Decoration you are making it impossible for me, or for others, to have the tabbed layout we want. That is to say, you decided your tabbed layout is the *right* one and that no other kind of tabbed layout *should* ever exist. That could be fine, but by doing so your are making it impossible the existence of a floating layout too. Just the idea of enforcing a given idea in Decoration is going to break decoration. I really didn't need to read David's code to know he was breaking my floating layout. His comment was enough. And indeed, I didn't read it. I just grabbed a clean source, built it, fired up Xnest and took the screenshot: http://gorgias.mine.nu/xmonadShots/droundyPatch.png (well, I was hoping for some of David's miracles, but I knew that was highly improbable in that situation, and given that comment). Now, in order to have a tabbed layout that is working smoothly with other parts of the system - your idea of a tabbed layout - we need to use a layout modifier. And I understand you think this is wrong. And since you think this is wrong, you think I must fix my code. What I'm trying to say is that, the problem is not the code, but the idea behind it. We have two conflicting ideas that are mutually incompatible. I see 3 possible solutions: 1. I change my mind; 2. you change your mind; 3. everyone changes her mind and we find a 3rd idea the is better then mine and yours. 1. and 3. are feasible for me. But I need to be convinced. 2 is out of my reach. Obviously there may be other solutions too I'm not aware of. Andrea ps: at the present time the repository is enforcing your idea with my code. This is why the repository is currently broken and, as far as my knowledge goes, there's no way to fix it.