On Fri, Feb 01, 2008 at 03:00:47PM -0600, Spencer Janssen wrote:

I think this solution is *really* ugly. Also, I don't think we can necessarily rely on the property that decorations windows are the only override-redirect windows in the windowset.

Sorry Spencer, but I deduce, from your words, that all my job has been base on completely false assumptions, and probably we must have some serious code review. I'm not kidding, and I'm not ironic. I do really take into consideration of just being plainly wrong on everything. You know I have high respect for your knowledge. 1) handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do wa <- io $ getWindowAttributes dpy w -- ignore override windows -- need to ignore mapping requests by managed windows not on the current workspace managed <- isClient w when (not (wa_override_redirect wa) && not managed) $ do manage w 2) a window with override_redirect *must* always pass true. 3) no modifier is allowed to change the stack set! they can *only* manipulate the (window,rectangle) list to be returned in Operations.windows. Modifier *DO NOT* manipulate the stack. Once "restackWindows d vs" has being called, track of layouts/modifiers' activity can be found only in the layout field of the workspace type. If any of these three assumptions is false, we should probably consider to revert immediately. I'm serious, and I understand that we must provide a certain level of code correctness. Cheers, Andrea

Hi Andrea (and others) I have only partly been following this discussion, but followed enough to have a pretty clear idea what was going on when I upgraded my xmonad today. As expected, tabbed stopped working, so I set out to fix it, and I hope I didn't step on anyone's toes. I'd vaguely been thinking about this, and I've now pushed my changes. Perhaps this was a little over-impulsive, but I hoped that by simple presenting a solution, we'd get over the apparent impasse this discussion has come to. Spencer is right that returning all the windows in a tabbed layout causes trouble, in particular my WindowNavigation setup with tabbed and combineTwo breaks. But I really like your approach of separating the decorator from the actual layout, it's very clean. I took the liberty of making Decoration remove the duplicate windows as it adds the decorations. This seems to me like the "right" approach (or perhaps I should say *a* right approach), as it only removes windows that have precisely the same rectangle, and it's not clear to me that you ever really want to actually make visible two windows that entirely overlap. This is also nice, in that at this stage there's no trouble telling which are decorations and which are "real" windows. I also added support for mouse clicking into Decoration, so that (modulo the need to avoid the broadcastMessage patch that breaks mouse support for tabbed anyhow) we now have fully functional tabs. Andrea, these changes you've made are really cool, and I do hope that you'll stick with it. It'd be a real shame to have you leave the project! David P.S. I've probably apologized enough already, but in case it isn't clear, you can feel free to rewrite or reverse these changes (preferably without breaking anything, of course).

On Sun, Feb 03, 2008 at 08:25:55PM -0500, David Roundy wrote:

Hi Andrea (and others)

I have only partly been following this discussion, but followed enough to have a pretty clear idea what was going on when I upgraded my xmonad today. As expected, tabbed stopped working, so I set out to fix it, and I hope I didn't step on anyone's toes. I'd vaguely been thinking about this, and I've now pushed my changes. Perhaps this was a little over-impulsive, but I hoped that by simple presenting a solution, we'd get over the apparent impasse this discussion has come to.

Spencer is right that returning all the windows in a tabbed layout causes trouble, in particular my WindowNavigation setup with tabbed and combineTwo breaks. But I really like your approach of separating the decorator from the actual layout, it's very clean. I took the liberty of making Decoration remove the duplicate windows as it adds the decorations. This seems to me like the "right" approach (or perhaps I should say *a* right approach), as it only removes windows that have precisely the same rectangle, and it's not clear to me that you ever really want to actually make visible two windows that entirely overlap. This is also nice, in that at this stage there's no trouble telling which are decorations and which are "real" windows.

I also added support for mouse clicking into Decoration, so that (modulo the need to avoid the broadcastMessage patch that breaks mouse support for tabbed anyhow) we now have fully functional tabs.

Andrea, these changes you've made are really cool, and I do hope that you'll stick with it. It'd be a real shame to have you leave the project!

David

P.S. I've probably apologized enough already, but in case it isn't clear, you can feel free to rewrite or reverse these changes (preferably without breaking anything, of course).

Ah, now this is a clever idea I hadn't considered. It still seems a little bit messy, but I think it will work just fine. In the long term, if we ever decide to generalize decorations, we can look at alternatives. Cheers, Spencer Janssen

On Sun, Feb 03, 2008 at 08:25:55PM -0500, David Roundy wrote:

Spencer is right that returning all the windows in a tabbed layout causes trouble, in particular my WindowNavigation setup with tabbed and combineTwo breaks. But I really like your approach of separating the decorator from the actual layout, it's very clean. I took the liberty of making Decoration remove the duplicate windows as it adds the decorations. This seems to me like the "right" approach (or perhaps I should say *a* right approach), as it only removes windows that have precisely the same rectangle, and it's not clear to me that you ever really want to actually make visible two windows that entirely overlap. This is also nice, in that at this stage there's no trouble telling which are decorations and which are "real" windows.

I don't have ready access to the source, now (I just had a glance from the web and, I must confess, I didn't get it at first sight, and I'm not in condition to have a closer look), and moreover I cannot even test it rapidly. But from your wording and this comment: -- We drop any windows that are *precisely* stacked underneath -- another window: these must be intended to be tabbed! I may have the feeling you did not get precisely Decoration's task and the TabbedDecoration style. I may just be wrong (in which case this is just the obvious for you), but a tabbed decoration is *not* a tabbed layout, and a tabbed decoration may be (and can be) applied to a Circle layout or to any tiled layout, just to have a place where you can see the names of all windows. That was a feature requested, that Decoration makes possible. Moreover Decoration is also used to decorate with the DwmStyle or the SimpleDecoration style (I'm using this with my sipmeFloat layout, which is actually my default layout, now). Decoration is just an abstraction layer over xlib calls to create, hide, and remove windows. The creation, hiding and distraction is, how can I say, type controlled. Sorry if this is just noise. Andrea

On Mon, Feb 04, 2008 at 01:02:33PM -0500, David Roundy wrote:

I understand that there are different decoration styles, but I also think it's reasonable to remove windows that are not viewable from the display stack. This won't have any effect on layouts like Circle that don't stack windows on top of each other, and in fact I can't see a scenario where you'd want different behavior.

as I said I didn't get the code at first sight and I'm not in the conditions to analyze it carefully enough. Still here you'll find a screenshot of my default layout after applying your fix: http://gorgias.mine.nu/xmonadShots/droundyPatch.png I think something is wrong in your patch, but I do not know what. Cheers, Andrea ps: my config is this: import XMonad import XMonad.Config.Arossato (arossatoConfig) main :: IO () main = xmonad =<< arossatoConfig

On Mon, Feb 04, 2008 at 07:48:03PM +0100, Andrea Rossato wrote:

On Mon, Feb 04, 2008 at 07:39:16PM +0100, Andrea Rossato wrote:

...

On Mon, Feb 04, 2008 at 01:02:33PM -0500, David Roundy wrote:

...

I understand that there are different decoration styles, but I also think it's reasonable to remove windows that are not viewable from the display stack. This won't have any effect on layouts like Circle that don't stack windows on top of each other, and in fact I can't see a scenario where you'd want different behavior.

as I said I didn't get the code at first sight and I'm not in the conditions to analyze it carefully enough. Still here you'll find a screenshot of my default layout after applying your fix:

http://gorgias.mine.nu/xmonadShots/droundyPatch.png

I think something is wrong in your patch, but I do not know what.

now I got it. I didn't get the fact the we need to call restackWindows with every windows visible on the screen, even decorations. And we must do that in Operations.windows.

I'm confused. Isn't that what xmonad does already? I thought that was the point of including the decorations in the list of windows that are output. Do you remove the decorations from the list at some later stage? -- David Roundy Department of Physics Oregon State University

On Mon, Feb 04, 2008 at 07:48:03PM +0100, Andrea Rossato wrote:

now I got it. I didn't get the fact the we need to call restackWindows

(btw, I supposed you didn't get it because in the old tabbed there was a call of restackWindows that, as far as I came to understand, was not producing any effect... just to avoid any confusion...;) a

On Sun, Feb 03, 2008 at 08:25:55PM -0500, David Roundy wrote:

I also added support for mouse clicking into Decoration, so that (modulo the need to avoid the broadcastMessage patch that breaks mouse support for tabbed anyhow) we now have fully functional tabs.

this part of the patch rises, I think, quite an interesting issue. I think that we should keep ordering information unique throughout the system, and *only* in the stack. I think Don will agree with me on this point. There is just one exception in the windowArranger. But from a practical perspective this only means that the arranged window (a window whose geometry has been modified by a user message sent to the arranger) will not change its position on the screen if you swap it in the stack. But it got swapped. Anyway, any modifier can trust the fact the focused window in the stack *is* the focused window, the first in the [(w,r)] (or the second if the first is a decoration). Your patch breaks this design and after Decoration the stack we pass to modifiers (redoLayout, etc) cannot be trusted anymore, which, I think, is bad. We could remove the stack from the type signature of those methods and just change our perspective, as you probably did. maybe this way is better. I don't know, but we should be consistent somehow, is which case this patch would be not enough. Just my 2 cents. Andrea ps: as you may observe, here I'm proposing to set aside the idea that a layout is a monolithic object, defined in a specific place in our source code. I think this is not scalable anymore, not when we start adding decorations and all that. Instead, we should create smaller components and put them together to create layouts. But we must hide everything to our users.

sjanssen:

On Fri, Feb 01, 2008 at 12:02:04PM +0100, Andrea Rossato wrote:

...

Hi,

this is a follow up of the discussion with Spencer about tabbed.

This patch implements WindowRemover. If placed over tabbed it should be removing unfocused windows, without touching the windows decoration.

WARNING: while this patch passes all tests both with ghc-6.6.1 and ghc-6.8.2, when I build this test file: import XMonad import XMonad.Config.Arossato main = xmonad =<< arossatoConfig

ghc-6.6.1 fails with this linker error: [12:00:33][wolf@laptop:~/.xmonad]$ ghc --make xmonad.hs Linking xmonad ... /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status

The same code compiles, and works perfectly (unless bugs introduced by its author, me) on ghc-6.8.2.

This is why I'd like someone to test it (I'll include it also in the bug tracker).

Cheers, Andrea

Fri Feb 1 11:55:05 CET 2008 Andrea Rossato * Add windowRemover for make tabbed return just the focused window

I think this solution is *really* ugly. Also, I don't think we can necessarily rely on the property that decorations windows are the only override-redirect windows in the windowset.

That sounds fragile.