* 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.ht... [2] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IM.html