Re: [xmonad] Tabbed.addTabs broken?

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