[xmonad] Tabbed.addTabs broken?

David Roundy droundy at darcs.net
Wed Feb 13 10:45:49 EST 2008


On Wed, Feb 13, 2008 at 11:12:34AM +0100, Andrea Rossato wrote:
> I also have some more general thoughts your mail generated.
> 
> On Tue, Feb 12, 2008 at 06:17:55PM -0500, David Roundy wrote:
> > I'm a little unclear here:  what is it that you want tabbed to do? I had to
> > make this change (I think) in order to make tabbed work properly when it is
> > placed in a subset of the screen.  Your tabbed was trying to draw the tabs
> > at the top of the screen regardless, as I recall.  Certainly we must use
> > the locations of the windows to determine the locations of the tabs,
> > otherwise everythings going to look crazy.
> 
> There are cases in which the window's location cannot be used, such as
> the case of a floating layout with a tabbed-like decoration. I think
> that in such cases we must use the screen rectangle a layout (or a layout
> modifier) gets in doLayout/redoLayout.

Why not use the input-rectangle that's given to doLayout? i.e. what if I
want to do something like this

  (fooLayout *|* tabbedLikeDecoration floatingLayout)

In this case I'd want the tabbedLikeDecoration to place its tabs on the
right hand side of the screen, on the principle that layout combinators
ought to work such that each layout only decorates in its part of the
screen.

In contrast, I'd expect:

 (tabbedLikeDecoration (fooLayout *|* floatingLayout))

to produce tabs covering the entire screen (and have tabs for all the
windows, not just the floatingLayout ones).

And I'd expect

(tabbedLikeDecoration fooLayout *|* tabbedLikeDecoration floatingLayout)

to produce tabs on the left-hand side for the windows on the left, and tabs
on the right for the windows on the right.

> LayoutModifier has the modifyLayout method for this purpose only:
> change the rectangle (or the stack, which is quite uncommon - no one
> is doing so right now) and produce the (window,rectangle) list
> accordingly.
> 
> But probably this is incompatible with what comes next.
> 
> > 
> > > But, as far as I understand, this is needed for WindowNavigation (I do
> > > not understand well its code, and I didn't have time to study it).
> > 
> > No, this bit is no longer needed for WindowNavigation.  It is, however,
> > needed if you want to apply this decoration to a more interesting layout
> > than Simplest.  (Which was required by WindowNavigation, prior to the patch
> > mentioned below.)  I do think this is a good idea, as it gives us a more
> > composable interface (i.e. we could combine layouts *prior* to adding
> > decorations, which might have advantages).
> 
> Applying decorations after combining layouts is definitely something
> *very* good. I'm wondering if this is compatible with the above.
> (Probably not?)

I think this is compatible with a tabbedLikeDecoration that obeys its input
rectangle (which ought to have a decent name, but I can't think of one at
the moment), as described above.

> (And so, this would answer also my previous mail, probably: a
> TabbedLikeDecoration style is *incompatible* with the possibility of
> decorating layouts after combining them).

I don't think it's incompatible with combinators, as described above.  Of
course, you could get very weird effects if you did something like

tabbedLikeDecoration (tabbedLikeDecoration fooLayout *|*
                      tabbedLikeDecoration floatingLayout)
-- 
David Roundy
Department of Physics
Oregon State University


More information about the xmonad mailing list