[wmii] wmii-3 and window 'z-index'/'z-stack' handling problem with the float layout

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.
Received on Sat Oct 14 2006 - 02:54:29 UTC