[xmonad] Tabbed.addTabs broken?

[David Roundy]

On Wed, Feb 13, 2008 at 10:34:24AM +0100, Andrea Rossato wrote:
> On Tue, Feb 12, 2008 at 06:17:55PM -0500, David Roundy wrote:
> > > Tue Feb  5 21:23:43 CET 2008  David Roundy <droundy at darcs.net>
> > >   * make tabbed work nicely with LayoutCombinators and WindowNavigation.
> > >   The problem is that WindowNavigation assumes all windows are navigable, and
> > >   it was getting confused by decorations.  With a bit of work, we can
> > >   decorate windows *after* combining layouts just fine.
> > 
> > I'm not clear what the problem is here.  The theory of addTabbed was that
> > the tabbed decoration should be able to decorate a "mixed" layout, in which
> > some of the windows are supposed to be tabbed, and others are not (and
> > those don't get decorated).  If it doesn't do this, then yes, it's broken.
> 
> It does so, and so it is not broken. My fault, since I thought it was
> just more general, and could be used for, say, Circle, or Mirror
> tiled.
> 
> At first Layout.Tabbed.hs was exporting a style that could be used
> with any layout, not just with layouts with stacked windows.
> 
> > > It also assumes the decoration to have the same y coordinate of the
> > > window to be decorated - the window must be shrunk. That is to say, if
> > > we were to remove the first constraint, we would end up with a
> > > SimpleDecoration layout modifier. :)
> > 
> > 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.
> 
> Now I think I get exactly the problem your patch was trying to solve.
> What I want is to have a tabbed-like (let's call it this way) that can
> be used with any layout.
> 
> For instance, a tabbed-like decoration that works with a floating
> layout:
> http://code.haskell.org/~arossato/xmonadShots/floatSimpleTabbed.png

I actually realized this yesterday when I saw your

http://code.haskell.org/~arossato/xmonadShots/circleSimpleTabbed.png

and realized that this could be useful.  It's also (as you say, and I was
thinking to write to you) a tabbed-like decoration, rather than a "true
tabbed" decoration, which is different--but both potentially useful.  Your
"tabbed-like" decoration actually serves the function of a gnome-like bar,
which lists windows present and allows you to give them focus.  As opposed
to the "true-tabbed" behavior which serves the same function served by
e.g. firefox tabs, allowing one to combine several windows together to
reduce clutter while still maintaining ready accessibility of the hidden
windows.

(I'm sure you understand this, but figure it's best to be clear when
possible, since we so recently had different pictures of what addTabs ought
to do...)

I can't help but wonder if a tabbed-like interface is best acheived by
supporting EWMH or something, so gnome-panel or kicker could serve this
function.  But there's no harm in having redundant means of acheiving the
same functionality.

> (Actually I'm not using such a layout, but I had a request for
> something like this).
> 
> What I was asking was that:
> 
> 1. can I change Layout.Tabbed.TabbedDecoration so that something like
>    this can be done with that style without breaking WindowNavigation
>    - and possibly other things? If yes, do I need to change
>    WidowNavigation? If this is another yes, how?

No, you shouldn't need to do anything with WindowNavigation to implement
tabbed-like decorations.  I presume you're thinking to have related
modifiers, one for "true-tabbed" and one for "tabbed-like" decorating? That
sounds like a good idea to me.

> > > 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).
> 
> This means that both option 1 and option 2 would work fine with
> WindowNavigation, without any change?

Right.

> > It's better *not* to use isDecoration, on the principle that we should be
> > checking for the actual property that we require (presense in the stack),
> > not for a different property that happens to be true for the same windows.
> 
> This is an interesting point. Probably I should just change
> isDecoration to use the stack, right?

Yeah, that sounds reasonable, depending on what you plan to use
isDecoration for.  If you plan to do anything "special" with decoration
windows (that you wouldn't want to have affect other xmonad-created
windows), then you'd still want some way to distinguish.  e.g. if we had a
modular prompt code, that'd create a window, which might not be considered
a "decoration".
-- 
David Roundy
Department of Physics
Oregon State University