[xmonad] "minimize" + "boringAuto" in Full-layout: focusUp and focusDown don't change focus

[Adam Vogt]

* On Monday, December 21 2009, Ralph Hofmann wrote:

>> I guess so, but I feel focus skipping of minimized windows is an
>> integral part of X.L.Minimize, so the module might as well do the
>> work itself of making sure the correct windows are marked as boring.
>
>I think so too. In my opinion X.L.Minimize should do its work without
>AutoBoring. Boring and Minimizing are different things und should be
>handled as such. But then we have three different focusing functions
>and maybe will have even more in the future from other moduls. That's
>probably not good.
>
>Instead of defining a complete focusing functions within a module,
>wouldn't it be better, to define only something like a
>focusingModifier?
>
>Thus we can write something like:
>
>myfocusingFunction = focusingModifier  coreFocusingFunction
>
>in monad.hs. The user can choose his preferred modifier and can even
>combine them:
>
>myfocusingFunction = focusingModifier1 $ focusingModifier2
>coreFocusingFunction
>
>
>Ralph

While what you described could work, you have to be a bit more indirect
and use class methods instead of actual functions because you need to be
able to show and read layouts. See the use of U.WindowProperties [1] in
for example L.IM [2].

That restriction means that you have a bit more boilerplate to write if
you wanted to define myfocusingFunction:

] data MyFocusingFunction = MyFocusingFunction deriving (Read,Show)
]
] instance FocusingFunctionClass MyFocusingFunction where
]   focusingModifier _ = mod1 . mod2

This approach doesn't seem to frees us from the difficulties of
documenting the correct order of composition however: it is probably
possible to define some other function for composing such functions,
that does flip the order of modifiers based on some kind of precedence
scale.... but such a thing should probably be used to correctly compose
layouts in general:

] import Data.Monoid
] import Data.List
] import Data.Function
] import XMonad
] 
] type LM a = (Int,Endo (Layout a))
] 
] sortMods :: [LM a] -> Layout a -> Layout a
] sortMods = appEndo . mconcat . map snd . sortBy (compare `on` fst)

And then somewhere every layout modifier is defined with a precedence:

] mirror :: LM a
] mirror = (0,Endo $ \(Layout a) -> Layout $ Mirror a)

And then used as such:

] , layoutHook = sortMods [mirror, decoration, minimize, borders, boringAuto] $ Tall 1 0.03 0.5

Perhaps with the appropriate type hackery, an operator for composing
modifiers could reorder the modifiers correctly. However, I can't figure
out how to get around the need to manually wrap the modifiers as 
(Endo (Layout a)) or equivalently (Layout a -> Layout a)

--
Adam

[1] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Util-WindowProperties.html
[2] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IM.html