Re: [wmii] summary of some #wmii talk on 2006-03-02

From: Doug Bell <>
Date: Fri, 3 Mar 2006 13:55:54 -0500

Anselm R. Garbe wrote:
> On Fri, Mar 03, 2006 at 04:11:19PM +0100, Uriel wrote:
> > It is trivial to create an action that pops the current client into a
> > new column.
> > Want 3 cols without even touching the exclusive flag? Just start 3
> > clients, and pop 2 of them into new cols.
> So we come to the point where we need a 'new column' action,
> right? So why do we need two ways then to create a new column?
> This discussion proves, that my decision yesterday has been
> right.

I'm not so sure that there isn't a better compromise that will give most
users what they want. Anselm wants to maintain column sizes when apps
are closed and to not have to tag columns as exclusive. The opposing
side doesn't want to waste space on empty columns and column bars.

As a compromise, how about something I'll call "column memory". When
the last app in a column is closed, the column disappears so that the
remaining column gets the space. But, when the next app is started,
wmii remembers that there was another column, so the app goes into a new
column with the old column's position and size. You would, of course,
need a command such as "forget column history" when you don't want this
behavior. Also, there would be a new column command that works like the
current snapshots, to place an active app into a new column initially.

This scheme eliminates many of the negative features of the other
approaches. Column sizes are maintained after apps are closed. Tagging
of columns is not necessary, since a apps would go into a new column if
the history exists and not otherwise. And no space is wasted on empty

Exactly how this works with three or more columns would need to be
defined, but I think it is possible to be consistent. And I think using
three columns is not all that common, so it probably souldn't be a big
driver of the design.

What does everyone think?

Received on Fri Mar 03 2006 - 19:55:56 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:00:40 UTC