Re: [wmii] Question about column layout

On Mon, Jan 23, 2006 at 04:08:39PM +0100, Stefan Tibus wrote:
> In this view LarsWM has something like this:
> *-+ screen
> |-+ page 1
> | |-+ tiled layer
> | | |- frame 1 (main)
> | | |- frame 2 (aside)
> | | |- frame x (aside)
> | |
> | |-+ floating layer
> | |- frame 1
> | |- frame x
> |
> |- page x

In wmii this is the same, with the exception, that the tiled
layer is called managed and cannot be raised - this is for
simplicity reasons to not make the concept unnecessary complex.
This allows the co-existence of transient windows like popups
of managed windows, though in general using several layers
per page concurrently is pretty annoying which is the reason, we
don't allow raising the managed area in front. This forces the
user to fit into the usage patterns of wmii, because he drops
the idea to use floating applications in the same page as
managed apps. The user tends to do this in different pages,
which is good.

But I agree that the additional layer called 'tabs' are a bad
idea after all and that they make the concept more and
unecessarily complex. In my opinion, tabs should be dropped in
general, because we have already the structural layer called
page. If anything doesn't fits into a page, just create a new
page.

> Frames in the floating layer may be maximized and it's possible
> to change (and move clients) between the tiled and the floating
> layer.

That is also in wmii the case. In the hg tip this is not
applicable through an atomic action, but you can do it through:

M-d M-space M-a

(I know that the drawing code does not updates both layer
correctly atm).

> An idea I'd favourize would be to have a stack of floating
> (includes maximized) frames (layers) and one (or more) may
> be assigned a management mode to include (sub)frames. Just
> think of stacking the pages as they exist now in one single
> page:
> *-+ screen
> |-+ page 1
> | |-+ layer 1 (managed)
> | | |- frame 1
> | | |- frame x
> | |
> | |-+ layer 2 (float/max)
> | | |- frame
> | |
> | |-+ layer x (float/max)
> | |- frame
> |
> |- page x

We already tried something similiar in wmii-1.x - but I got
convinced pretty fast, that nesting was a bad idea and that
structures for organizing windows should be as flat as possible,
to reduce the necessary navigation interaction to a bare minimum
and to make the concept pretty fast. That is why I don't like
tabs, because they introduce an additional (unnecessary) layer
to navigate among clients within a frame. That is also why I
think dropping tabs completely is a good idea. The only reason
why I kept them so far (theoretically) is, that I'm not sure
yet, how to handle maximized windows.

If I understand you correctly, we only need one kind of
maximization in each layout, which means, that the floating
layout would maximize a window to the screen size, and the
column layout to the column size. If a popup occures in a
maximized window, it will always be in front, because it is
always attached at least and attached to the floating layout (if
it has set the TRANSIENT_FOR hint).

Thus my structure would look like:

*-+ screen
  |-+ page n
  | |-+ floating
  | | |- client n
  | | |- client n+1
  | |
  | |-+ managed (if any)
  | |- client n
  | |- client n+1
  | |- client n+2
  |
  |-+ page n+1
  
> The current cycling through frames on a float/max page would
> turn into cycling between layers and within a managed layer
> one could cycle between frames...

As I told, thus introduces at least an additional layer, which
means you need 4 kinds of navigation shortcuts:

  - navigating pages
  - navigating layers
  - navigating frames
  - navigating clients
  
Simplier to remember and also efficient is:

  - navigating pages
  - toggling area (if a managed is present)
  - navigating clientsiS

> The screen has a stack of pages, a page has a stack of layers,
> a layer has a stack of frames (which it might manage or not)
> and a frame may have a stack of tabs...

Except the layers, I think this applies to wmii already, whereas
I plan to remove the tabs.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361