[xmonad] one more layout
vogt.adam at gmail.com
Sun Apr 5 20:46:00 EDT 2009
* On Friday, April 03 2009, Konstantin Sobolev wrote:
>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
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.
>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
>- 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.
More information about the xmonad