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