[Xmonad] Configurable tiling algos

[Donald Bruce Stewart]

droundy:
> On Thu, May 03, 2007 at 11:41:18AM +1000, Donald Bruce Stewart wrote:
> > Regarding configurable tiling, a simple strategy would be to have 
> > user-specified tiling functions available from Config.hs, of the type
> > 
> >     tile :: Rational -> Rectangle -> [Window] -> [(Window, Rectangle)]
> >     type Tiler =Rational -> Rectangle -> [Window] -> [(Window, Rectangle)]
> > 
> > so,
> > 
> >     myTile :: [Tiler]
> >     myTile = [someTileAlgo
> >              ,someOtherAlgo
> >              ]
> > 
> > These functions are then added to the list of algos to cycle through in
> > mod-space, and would allow custom pure functions.
> > 
> > David, I suspect you actually want 'tile' to live in X, so you can do
> > window name lookups and so on?
> 
> Possibly.  I'd actually probably prefer passing in something like
> [(ExtraWindowInformation,Windowj)] instead of just [Window].  The downside
> would be that we'd have to get the ExtraWindowInformation (title, class,
> etc) whether we need it or not, but I suspect that wouldn't cause too much
> trouble.  Or perhaps we'd want to define a new data type:
> 
> data PureWindow = PureWindow { thewindow :: Window
>                              , thename :: String
>                              , ... }
> 
> It's a little annoying (to me, anyhow) that the Eq instance of Window
> sometimes returns true between an old closed window and a newly opened
> window, so creating a new data type that doesn't have that issue might be
> handy.
> 
> But my first and primary objection is that you've constrained all tiling
> algorithms to have at most one Rational of user-configurable data.  To
> quote an early version of my extensible layout patch, I'd prefer something
> more like this as a starting point
> 
> +data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)]
> +                     , modifyLayout :: String -> Maybe Layout }
> 
> This allows each layout to have an arbitrary amount of user-configured data
> which can be configured at runtime.  See my mosaic module for a layout in
> which the prefered size and aspect ratio of each window may be individually
> tailored (although I didn't implement arbitrary aspect ratios for each
> windows, it's either square or all the same configurable value).
> 
> Then the available layouts are a [Layout] as in your case.
> 
> The key is in the modifyLayout method, which allows you to pass new data to
> the layout (e.g. changing a window size or something).
> 
> 
> 
> With mutual recursion (yuck), we'd probably want:
> 
> data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)]
>                      , modifyLayout :: LayoutMessage -> Maybe Layout }
> 
> where LayoutMessage is defined in Config.  But I really hate mutual
> recursion.  Not that I have much experience with it, since I never use
> it...

Regarding this last point, I find the use of Dynamic (let alone String)
a bit irksome in the current code. We have all the possible layout
messages known statically, since we statically compile and link
Config.hs. So we should be able to take advantage of that, and have
message handling code checked. 

So yes, given we already have mutual recursion on Config.hs, exporting
the data type from Config.hs, with the upside that we delay no type
checking to runtime of message forms, seems like a win to me.

-- Don