[xmonad] one more layout

[Adam Vogt]

* On Friday, April 03 2009, Konstantin Sobolev wrote:

>Hello,
>
>Could somebody review my attempt to write a layout and tell if it's
>worth including in contrib?

I found a couple of issues that should be corrected in the documentation:
    1. Refers to XMonad.Utils.WindowProperties, should be 
    XMonad.Util.WindowProperties
    2. Class should be ClassName

Combo deals with tabbed's requirement that it be told whenever the layout 
changes (I think that it is due to the ReleaseResources that it sends).

Perhaps the same results would be possible as a LayoutModifier around Combo 
that places certain windows in the layout at specific spots in the stack, 
when they have not been seen before (ie. keep track of the windows laid out 
in the previous run). That way you can avoid dealing with the specifics of 
dealing with decorated sublayouts.

>Inventively named ComboP, it mostly acts as CombineTwo, but also takes
>a predicate which controls new windows placement.
>For instance
>
>withIM (1%7) (ClassName "Tkabber") Grid
>
>is roughly imitated by
>
>combineTwoP (TwoPane 0.1 (1/7)) (Tall 0 0.1 (1/2)) Grid (ClassName "Tkabber")
>
>Also, a few notes/questions from an XMonad newcomer:
>
>- I see a lot of flickering when switching workspaces or tabs in
>Tabbed. Looks like root image is shown first,
>and then windows paint on top of it. It's very noticeable, especially
>when some windows are slow to redraw.

Tabbed is a relatively slow layout, but even then, I think that most of the 
redrawing delay can be blamed on the applications being slow to redraw. It 
seems to be less noticeable when using a black root window colour.

>- ResizableTile doesn't work correctly when placed into some
>combinator which feeds only a subset of windows
>to it(?). For instance try this:

I think that happens because of two calls to 'gets windowset' in its 
handleMessage: it grabs the whole list of windows even though it is only 
passed a couple. Other than changing ResizableTile, the layout modifier
could run the modified layouts in an environment where the StackSet only 
contains the windows that the sublayout should care about. That approach is 
going to lead to difficulties in with merging the modifications that the 
layout makes to the WindowSet (just ignoring the changes will probably lead 
to as many issues as just naively running the modified layout with the 
common environment).

>- dragPane doesn't work when reflected
>
>The idea of layout combinators looks nice, but overall impression is
>that different combinations haven't
>been tested thoroughly.

There many combinations, and its probably true that all combinations have 
not been tested. I'd say that these issues are due to the layout modifier 
breaking some invariant that the modified layout assumes to be true: for 
the dragPane, I'd expect that the mouse handling stuff still assumes that 
the divider is a vertical one, when it has in fact been changed. Such are 
the issues of impure layouts; they are harder to test and easier to break 
by changing the environment.

In any case, if you run across an issue, file a bug and/or notify the 
maintainers: it could be that such a combination has not been tried before 
and maybe the solution isn't difficult at all.

Thanks,
Adam