Hopefully this patch fixes the ambiguity. That state information (that int parameter) as to which aspect ratio layout to pick is now hidden, since I could not think of a good reason for it not to be the default. * On Sunday, January 25 2009, Roman Cheplyaka wrote:

Applied, thanks. A few issues with documentation: - what does Int (0 in your example) stands for? - "The numbers are directly proportional to the area given, with the master window getting the most if you have an ascending list." -- does it mean that area of master is proportional to the last number in the list? I think it should be more clear.

-- 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

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

Another update to Mosaic. (I don't know why 2 patches ended up in this bundle), but darcs thinks it should be that way. * On Monday, January 26 2009, Roman Cheplyaka wrote:

Ok, applied that one.

-- 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