Re: [wmii] columns

From: Doug Bell <>
Date: Fri, 26 May 2006 06:21:59 -0400

Anselm R. Garbe wrote:
> On Fri, May 26, 2006 at 02:22:19AM -0400, David Bronke wrote:
> > First, I'd like the ability to "split" a given column so that the
> > other columns of the view remain unchanged. Instead of the standard
> > way of creating a new column (simply moving the client to a new
> > column) it would keep the same geometry for all columns except for the
> > one being split. I imagine there would have to be "split left" and
> > "split right"... the former would create a new column in the left half
> > of the current column's area and resize the current column to take up
> > the right side. The currently-selected client would then populate the
> > new column on the left. The "split right" would simply be the reverse
> > of this.
> In hg tip there is a newcol action, which creates a new column
> prev/next to the selected one (instead at screen boundaries).
> However taking up only half of the space of the existing one
> doesn't sounds very dynamic to me, but I'm not sure with this...
> What do others think about such a newcol strategy? We have
> /def/colwidth which defines the width of newly created columns,
> but I'm unsure of the need for it and didn't liked this option
> since the beginning. A /def/ncol option seems much more senseful
> in my eyes (like acme -c).

I'm looking forward to having a /def/ncol option. That will create the
next app in a new column if there are fewer columns than the setting,

> > Another feature I'd like is the ability to create rules for given
> > clients allowing them to be automatically be put in their own column
> > of a given size. This would be especially useful for eg. gaim, since
> > the buddy list window doesn't need to take up the full width of one
> > screen.
> This requirement sounds too static to work well in a dynamic
> layout. Why not making the gaim stuff floating by default and
> tagging it with 'chat' or something similiar, instead?

Another idea would be to generalize the size-hint idea from the dockapp
discussion. A preferred height and/or width could be set by window
class in wmiirc. The size-hint could be ignored if it's not possible
due to not enough rows/columns or due to multiple apps with conflicting
hints. But it would otherwise give the preferred size.

Received on Fri May 26 2006 - 12:22:01 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:06:58 UTC