Re: [dwm] The wmii layout and some help bout the mailing list

On Wed, Jul 02, 2008 at 02:54:41PM +0200, QUINTIN Guillaume wrote:
> Each time I want to post I start a new thread, how do I do to answer
> somebody ?

The Reply-To defaults to the list, so it depends on your MUA.

> Well, adding a void* aux to the Client structure sounds like a good idea
> but it is a first step towards adding "official" (or simply more
> advanced) support for plugins, I think. I mean that you will have to add
> an argument to the function lt->arrange indicating to the layout arrange
> function what action was performed on the window. This way no
> modification of the file dwm.c is needed, the patch (or plugin) can hold
> in a separate .c file with an #include only in the dwm.c. I think that
> it is a choice that has to be done. Plus, it won't add many lines (well
> to be sure I should try it !). This way no modification of the dwm.c
> (just an #include !).

Hmm, how would an action argument to arrange() help? What might
this argument look like?

> To do with the current version without modifying the dwm.c. It is
> "simple". I thought of that before. It suffices to add a "compare"
> algorithm which compare the wtable and the clients linked list to see if
> some windows were added or deleted or simply moved into another tag, etc
> ... But such an algorithm is (not complicated to write) long in terms of
> line of code and it will take much more memory than hooking into the
> dwm.c (That's why I decided not to implement it). In some way the
> wlayout function is a beginning of the algorithm. It checks if the
> windows tag has changed in the clients linked list and report the
> changes to the wtable.

Well as I told, the wmii column layout is rather static, because
it keeps certain clients at a fixed position (in a specific
column, at a specific position).

In contrast to this, dwm is designed for layouts which are totally
independent from clients itself.

There might be some ways to deal with a wmii-like approach in
dwm, however they always will end up in heavy patching.

A very simple wmii-like layout in dwm would be independent from
the actual clients, but remember the basic column/cell
configuration. First of all I noticed when I used wmii that I
never used more than 3 columns, so one could restrict the layout
to 3 columns at maximum. Secondly, there needs to be a column
which accepts any amount of clients, which could be restricted
to the last column. So if 1 column is in use, this takes
arbitrary clients, if two columns are used, the second takes
arbitrary clients (like current tile()), if 3 are in use the 3rd
takes arbitrary clients. Then you need a function to restrict
the number of clients in the first and second column. This could
be made dependend on the amounts of columns in use, to make it
even simplier. So one could argue, as long as the number of
clients in column 1 is not restricted (0) there won't be a
second column. If it is restricted, a second column will be
created if at least 2 windows exist and so forth.
If the second column is restricted as well, a third will be
created if both, first and second column are full. zoom() will
always move a client to the top of the first column. The rest
would work straight-forward with current dwm and without any
patches.

The patch would contain:

some local static data
coltile() -- as arrange algorithm
restrict1() -- restricts column1
restruct2() -- restricts column2

One would have:

Mod1-c to activate this layout
Mod1-i restrict1(.i = +1)
Mod1-d restrict1(.i = -1)
Mod1-Shift-i restrict2(.i = +1)
Mod1-Shift-d restrict2(.i = -1)

And that's it already.

Kind regards,

-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361