* 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