Hi there,
I'm tired of making too radical changes, I really like the
behavior as it has evolved so far and I don't want do big steps
anymore, except what's on TODO. If someone needs a LarsWM-alike
layout, there is LarsWM. If someone needs static window
management, there is Ion. wmii is different.
The idea to extend tagging with column hints sounds cumbersome
to me, especially because there is a big flaw in it. You cannot
see a client twice in X (that's why a tag can only be
view-specific), otherwise a client could only have one tag.
No, reducing the concept to two columns makes no sense to me.
Yes I know that wrapping on boundary when changing focus
horizontally has its pros and cons, we decided against it, to
make it more consistet with moving.
The column splitting is worth rethinking. I really like the idea
to remove /def/col*, but I'm not sure about the idea to split
depending on the previous column width. We already discussed
things earlier this year, and came to the conclusion that we
need splitting which preserves the geometry of each number of
columns and frames. This is already the case, because wmii
scales (grow/shrink) all existing columns before the new column
appears accordingly its current size (this won't happen with the
column split). With splitting based on the column width, you get
into corner cases very easy, which are less predictable than the
current behavior, e.g. assume
AABCC
AABCC
AABCC
If B is closed, which column is grown? A or C or both? The
current way is pretty much acme-like. And with 1600x1200 I
regularly use 3 columns and I'm happy they fill up my screen
equally sized - if you still use columns in a LarsWM way, I
really recommend upgrading to a saner screen with higher
resolutions if possible (yea I know, Laptop with 1024x768...)...
The only feature which I consider useful is to have /def/ncol
with following syntax:
/tag-regexp/ -> ncol
Similiar to the rule syntax, this will allow to define the
number of columns which should be created by default on the
specific view.
Regards,
-- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361Received on Mon May 29 2006 - 09:16:03 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:07:07 UTC