The MosaicSt constructor could probably be directly used, but then I think that using a single constructor would demand an unwieldy one like:
data Mosaic a = Mosaic (Maybe (Rational,Int)) [Rational]
Since initially, the two parameters (the current index of the list of possible arrangments, and the maximum index) will be determined by the number of windows in the stack. Using just that constructor, with the layout being:
mosaic = Mosaic Nothing
could work too, but the difference is that pattern matching then requires 4 extra parentheses. Of course, having the explicit Maybe there might make the function of those parameters a bit more obvious. It's really just a small change to the top level. When the list is not ascending, the master window can be smaller than the next window, which is confusing since shifting a window up in the stack or promoting it can make it smaller. I don't think that we should be encouraging such inconsistent behavior (with respect to the standard layouts). I have also not experimented with zeroes and negative numbers, since those could cause a division by zero, and because of scary output like: XMonad> splitHorizontallyBy (-0.5) $ Rectangle 0 0 10 10
(Rectangle {rect_x = 0, rect_y = 0, rect_width = 4294967291, rect_height = 10},Rectangle {rect_x = -5, rect_y = 0, rect_width = 15, rect_height = 10})
Which is almost certainly not going to be liked by the xserver. I still have to resolve the issue where the user has to reset the layout or adjust the aspect ratio after adding some windows to an empty workspace: at the same time, I don't want to set the aspect ratio to the default one after the user has explicitly set it to be something else. (maybe keeping track of whether a Taller or Wider message has been received...). * On Sunday, January 25 2009, Roman Cheplyaka wrote:
Have you introduced another data constructor only for hiding the layout state? In this case you can introduce just a mere function:
data Mosaic a = Mosaic Rational Int [Rational] mosaic = Mosaic 0 0
and export only mosaic. Or there are some other reasons I don't see?
Also, it's still unclear what will happen if the list is *not* ascending.
-- Roman I. Cheplyaka (aka Feuerbach @ IRC) http://ro-che.info/docs/xmonad.hs _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad