I'm not too sure why nobody has raised this issue yet (i've searched the list for what it's worth), but here's my problem with the float layout. After analyzing, and thinking about it, I think i can understand the logic (as in, the *programming* logic, not as in, "make-sense logic") behind why the "z-axis stacking" (for lack of a better term) is done this way, but i would still like to point out the issue and bring it up for discussion, as i think it presents sort of a "non-intuitive" (and possibly quite disorientating as well) way of doing things.
Here's the issue: set ur workspace to float layout. Open up several windows (the best way to do this quickly would be to call up several xterms quickly). Now cycle through them with Mod-j. "Cycle round" several times. Notice how the overlapping (or "z-axis stacking") is kind of non-intuitive, and quite possibly disorientating as well? (*If this effect is not immediately obvious, try opening yet a few more windows, and then try cycling through them again). I can understand the programming logic here (which seems to me to be something rather similar to "keeping as much of the titlebar visible as possible for ALL windows without violating the ONLY one necessary rule of keeping the current window at the absolute top"), but i would think that from a "window management" point of view, doesn't it present somewhat of an ~obstacle~ to the user instead? Now i know that the aim (or one of the aims) of wmii is to "manage the windows for the user" - but shouldnt the management be done in a way that ~benefits~ the user, rather than otherwise? (which is what the "auto-window-management" is for in the first place)? What we have right now in terms of "z-stacking" handling is at best just non-intuitive - and at worst going against the very intentions of the user. Consider the old wmii-2 way of handling the float layout in terms of z-stacking - it was very intuitive, and quite plain and simple. What u expected (intuitively) was what u really got. If u had window 1 at the top of the z-stack, and then subsequently brought window 2 up to the top (by cycling to it), window 3 and 4 did not also pop up to the top too for no apparent reason to obscure window 1. The natural user will naturally start to think... "what the .... for????" Now imagine the new way of doing things. I have window 1 at the top. Now i bring window 2 to the top, and want to retain window 1 in the background, because i still want to refer to it for information that i will need in window 2 - but instead i notice that window 3 and 4 come up as well, to obscure the info that i want in window 1. So i cycle around again. The same thing happens. So what am i forced to conclude here? That if i want to have reasonable z-stack handling and a float layout, i can only have at most 2 windows, or will have to plan my window positions very nicely (back to the WIMP paradigm, which is what we sought to get away from)? Or that I must be forced to accept a 50-50 width size for my windows (the width allocation for the columns is not adjustable, unlike wmii-2), and use multiple columns instead? But what if i (very frequently for me, and i'm sure for more than a few others as well) want to pair one necessarily BIG window, say a browser, with one smaller one, say an xterm? The 50-50 split will make my xterm bigger than it needs to be... and my browser window so much smaller than it should be. Your comments, ladies and gentlemen? -jf ps. i am aware that wmii is now scriptable, and perhaps, just perhaps, all this might be reasonably solvable, or "workaround-able" with a script in place, but still... i would like to think that the natural state of the WM (without the scripting) should be something constructive already. Thanks for reading this, and thinking about it, and for giving ur comments if u have any.
