[xmonad] The future of Decoartion

[Andrea Rossato]

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.