[xmonad] darcs patch: A mosaic layout based on MosaicAlt

[Adam Vogt]

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 at haskell.org
>http://www.haskell.org/mailman/listinfo/xmonad