On Mon, Jan 23, 2006 at 04:46:10PM +0100, Anselm R. Garbe wrote:
> 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.
Well...actually if I have some window floating (what ever the
case may be to have it so) I'd anyways like to be able to access
a covered window on the managed layer. Personally I find it
annoying having to move that floating window away (to another
page) first. Furthermore, pages are useful to group programs
together, so it's not intuitive to force fullscreen windows to
other pages, in order to access managed clients.
> 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.
Agreed.
> 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.
Well, that's already an extended variant of what I thought of,
but sounds good. It would then be useful to move a client between
the two layouts and optionally (un)maximize it at the same time
(e.g. to switch from within a column to fullscreen and back).
> 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
>
> Simplier to remember and also efficient is:
>
> - navigating pages
> - toggling area (if a managed is present)
> - navigating clients
Agreed.
Regards,
Stefan
Received on Mon Jan 23 2006 - 18:57:40 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:59:49 UTC