Re: [wmii] Column Layouts

On Fri, Apr 28, 2006 at 10:28:03AM +0200, Stefan Tibus wrote:
> However, for the future one could think of extending the
> column-layout maybe to a matrix-layout. Why should I be forced to
> arrange my windows in columns? And that's probably the point some

The main reason to have columns instead of smaller matrix cells
is simplicity. Not only from implementation POV, but also from
user's point of view. It reduces movements among cells to a
single dimension, it makes the effects of resizing a column more
simple, and it scales better - in my opinion. It also avoids
several corner-cases.

The column concept is organized as two layer concept, columns
split up the horizontal space, clients the vertical space. That
is simple and easy to adapt.

> people have problems with. In order to have two visible clients
> in a column and the others stacked or hidden, one needs to split
> the column. On the other hand, I may as well like to arrange my

With my proposal in the other mail one don't needs to split
columns.

> But generalizing the current approach is not easy, there are some
> possible ways coming to my mind, but each is somewhat clunky:
> 1) The screen splits up like a matrix with variable row and column
> sizes and within one cell you may have column/row/max layout.
> If you don't introduce shortcuts to select those cells, moving
> across cells involves moving through all clients within that
> cell.
> 2) Do some nesting of columns and rows. Current wmii can be thought
> of a single row in column mode. New clients are added to the
> current column and can be moved to new columns (left/right).
> Now one could think of having a column in row mode. New clients
> would be added to the same row and could be moved to new rows
> (up/down).
> However, again the selection of specific clients (moving around
> among the clients) is not straightforward.

Yes, both concepts don't look simple.

> Any implementation of something more variable than just columns or
> just rows will need some additional structuring and thus some
> additional keybindings to move around, which is not wanted.
> Though I'd like to be able to have something like e.g. a row of
> clients above my columns, up to now I have to admit myself I can't
> see a good way to this (some certain layouts may be implementable,
> but not the full flexibility...).

Actually it would be possible to reuse the complete column-based
algorithm for a row-based algorithm through simply inverting the
directions currently in use with +90 degree for columns and -90
degreee for clients. If the code is well-designed this needs
changes in maybe 4 lines of code.

> So having the screen as a single row (column) and only allowing for
> columns (rows) containing the managed clients within that appears
> best for now. And to come back to the beginning: I believe it's

But there are drawbacks with this, first it would add an
additional layout to the user's point of view, second the
stacking won't work in rows without vertical titlebars which
would suck pretty much, because they are annoying to use for
input tags.
Thus all in all I think fine-tuning the columns is the way to
go.

> ok to simply admit a certain functionality is not available and
> may as well not be provideable in future. However, I don't think
> it's fair to just say "you don't need it, because you can do it
> in another way" - people have different ways of thinking and
> different ways of working...

Actually I haven't seen any application yet, which would fit
better in a row layout. There are rare cases where the IDE
layout

AAABBB
AAABBB
CCCCCC

could make some sense, but in the end there are ways to handle
this in columns as well, ie:

AAABBB
AAABBB
AAACCC

It mostly only depends on your physical screen. If it is too
small, you maybe should consider to buy a bigger one ;)

The main advantage of the column layout is its simplicity and
straight-forward way, that it does not allow all the kinds of
layouts you can achieve with ion for instance.
Once you see this as advantage you might notice, that lesser is
more.

Regards,

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