[Xmonad] darcs patch: An alternative mosaic layout implementation

Jamie Webb j at jwebb.sygneca.com
Wed Oct 3 12:40:28 EDT 2007

On 2007-10-02 07:28:06 David Roundy wrote:
> On Tue, Oct 02, 2007 at 02:45:12AM +0100, Jamie Webb wrote:
> > This is a new layout which is very similar to David's Mosaic, but
> > produces different tilings. The algorithm is simpler, but I think
> > it gives more useful results. It divides the space in a more
> > balanced way, in particular trying to avoid very narrow windows.
> This looks pretty nice, although it is less flexible.  The algorithms
> that Mosaic uses need to be totally rewritten, but I like the ideas
> behind them (which is to write down a "goodness" function and then
> minimize it).  The trouble is that discrete minimization is hard...

Mmm... makes sense, though I wonder if it's not an unnecessarily
general problem. I've had a bit more of a play and I think I have a
reasonable compromise: I break the windows into an arbitrary
area-balanced tree as before, but then I use the minimisation approach
to select the screen divisions. The tree constraint means that I can do
it exhaustively in quadratic time, which should be easily fast enough
for reasonable numbers of windows.

The results are presumably not always optimal, but they seem to be
pretty good. The main disadvantage is that windows jump about a lot as
the layout changes.

I've also made the target aspect ratio modifiable for each window.

The trouble is that this is fine for xterms and the like, and it seems
like it /can/ give good results for other sorts of windows, but too much
fiddling with areas/aspects is often required: it would be easier to
drag borders about. It needs to select more sensible defaults based on
the window type. Maybe it can use the geometry that the application
initially asks for? I'm not sure how to do that.

> but the real reason that Mosaic has languished is that Combo works
> better for me.  Dynamical tiling just has trouble competing with
> static tiling intelligently laid out. Particularly when the dynamical
> tiling is constrained to display all windows--very often there *is*
> no useful way to display all windows.

Yes, I was pretty happy with Ion for something like five years until I
found Xmonad a few days ago, and I still think Ion's model probably
works better overall, at least for now. A WM that's so easy to hack on
was just too tempting though...

I think MosaicAlt works very well for a suitable number of xterms,
and passably for some other cases. Aside from that I'm mostly using a
fullscreen Tabbed at the moment.

I'm also using a Combo of ResizableTile and Tabbed sometimes, but I'm
not entirely happy with it: as you say, there's difficulty in getting
the right set of windows visible. Perhaps you have a better setup than
mine? Do you mind posting your layout config?

At the moment, my feeling is that it would be better if the user were
able to move windows manually between Combo sub-layouts, rather than
just assigning a fixed number to each one.

> So if I get around to working on Mosaic again, I'll probably work on
> finding a way of mingling it with something like Tabbed, so that it
> can ensure that every visible window is usefully visible (e.g. no
> xterms less than 80 chars wide or two chars tall, and no emacsen less
> than 80 chars wide or two dozen chars tall).  This will also have the
> benefit of both making the algorithm faster (fewer windows displayed
> means exponentially fewer possible tilings) and as a result simpler
> (e.g. we may be able to try exhaustive search of tilings, provided
> window areas are kept fixed).  The trouble is figuring out which
> window to hide when the user clicks on one of the tabs.  Plus, I
> don't have much time for xmonad hacking.

That sounds nice, but I imagine that it might be an impossible
task to usefully guess which windows the user is looking at. Let me
know if you have any ideas, and I may have a go.



More information about the Xmonad mailing list