[Xmonad] darcs patch: An alternative mosaic layout implementation

[David Roundy]

On Wed, Oct 03, 2007 at 05:40:28PM +0100, Jamie Webb wrote:
> 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.

Sounds like a neat approach.  Jumping windows is an almost-unavoidable
side-effect of the mosaic-style layout.  It's lessened if you always put
larger windows to the left/top when possible (if the user defines a
continuum of window areas).

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

Yay!

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

Yeah, using window hints was definitely in my plans for mosaic.  I know
there are places where you can find examples of window hints code, and
that's what I'd do for some of these properties.

Also I'd like a property (per window) of "min/max width" "min/max height"
etc, which would mesh well with hints.  I think you could adjust this (in
principle) by key combinations + dragging borders, but probably you'd
mostly want it set by manageHook, so all xterms start out with appropriate
minimum dimensions.

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

I just have two layouts at the moment, fullscreen tabbed and

                 ,Layout $
                    combo (combo (Mirror $ TwoPane 0.03 0.8)
                                 [(Layout $ TwoPane 0.03 0.8,1)
                                 ,(Layout Square,1)])
                          [(mytab,8),(mytab,30),(mytab,1)]

The square is because I prefer to keep an xclock visible at all times.
Basically, this gives me a big window (I've got a 1024x768 laptop screen)
for editing and a little one for a shell (for compiling, usually), and tabs
all round so I can view lots of windows.  I'd use a different setup with a
bigger screen, where I could put two useful windows (other than an xclock)
side-by-side.

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

Yeah, Combo could be extended in this direction, which would be good.
Basically we could keep the current data structure, but add messages that
would have the effect of changing the number of windows shown in each
sublayout.  One trickiness would be figuring out how to handle nested
combos (i.e. to send the messages to the "right" layout).  And we'd want to
have Combo probably synchronize changing the number in each sublayout with
a reordering of windows.  This might be done something like the new Swap
message in WindowNavigation.

But ultimately, I think we'll be heading towards insanity if we're forced
to emulate all nested-stack transformations in Combo.  Proper handling of
the float layer requires nested stacks (in my opinion), and I'm hoping that
by adding this support we can sneak nested stacks into the core.

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

Right, you can't figure out what windows they're looking at, but you could
display, for example, the N windows that most recently had focus.  And you
could add a message that will ensure that the currently focussed window
always remains visible (for something like an xclock that you want to see,
but don't want to focus, or a kpdf set on autorefresh displaying the paper
you're working on).
-- 
David Roundy
Department of Physics
Oregon State University