[xmonad] darcs patch: A mosaic layout based on MosaicAlt
Adam Vogt
vogt.adam at gmail.com
Sun Jan 25 16:57:51 EST 2009
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
More information about the xmonad
mailing list