
On Mon, Feb 11, 2008 at 05:01:40PM +0100, Andrea Rossato wrote:
There are 2 patches I don't understand.
This one breaks Tabbed.addTabs:
How does it do so? What happens that is wrong?
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. since Tabbed now assumes that the windows to be decorated are only those with the same rectangle: wrs' = filter ((==r) . snd) wrs
Which is fine only with Simplest. If you use it with some other layout (which does not give the same rectangle to all windows) then this will always hold: if length wrs' <= 1 then Nothing
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 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.
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).
Which brings me to this patch:
Tue Feb 5 21:35:56 CET 2008 David Roundy
* make WindowNavigation ignore decorations. where you check the stack to see if a window is a decoration.
There is also another way to check if a window is a decoration, by checking its attributes (isDecoration :: Window -> X Bool does this).
I think this patch does things the right way. Why use isDecoration when we can just check whether the windows are present in the stack? By definition, the windows we want to focus are those which are in the stack. i.e. it's not necessarily just decorations we want to filter out, but specifically any windows that aren't part of the stack. 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.
I'm writing because I wonder if we can remove that constrain from Tabbed and solve the WindowNavigation problem in another way.
Which constraint was this in Tabbed? The one that requires it to only display visible windows? On slower computers (e.g. my laptop) it is very important to actually hide hidden windows, which is quite unrelated to WindowNavigation, simply to the fact that it's very hard to use the window manager when the screen keeps flashing between different windows when I change focus. I haven't upgraded my xmonad since I wrote these patches, and doubt I'll upgrade any time soon (there's always the possibility when upgrading that I'll lose a half-day of work getting thing going again like they were before...), but my feeling is that tabbed and WindowNavigation aren't very broken (unless they've gotten more broken). -- David Roundy Department of Physics Oregon State University